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关于 作者 


林 沛 满 ，2005 年 毕业 于 上 海 交 通 大 学 ， 现 任 EMC 网 络 存 储 部 门 的 
主任 工程 师 。 多 年 来 为 多 个 产品 团队 提供 过 技术 咨询 ， 范 围 包 括 网 
络 、 操 作 系统 、 文 件 系统 和 域 等 ， 这 束 是 本 书 所 涵盖 的 协议 如 此 五 花 
八 门 的 原因 。 每 年 临近 加 薪 的 日 子 ， 他 也 会 组 织 一 些 技术 培训 来 提 酝 
上 司 ， 本 书 的 部 分 内 容 束 来 自 这 些 培 训 资 料 。 

平时 他 也 写 一 些 技术 博客 ， 你 或 许 还 能 在 IT168 或 者 ChinaUnix 技 
术 社 区 看 到 它们 ， 本 书 也 有 少数 内 容 来 自 这 些 博客 。 他 也 是 
《Wireshark 网 络 分 析 就 这 么 简单 》 的 作者 。 

当 林 先生 不 在 工作 时 ， 大 部 分 时 间 都 花 在 了 园艺 花卉 上 ， 尤 其 是 
欧洲 月 季 。 


致谢 


我 那些 没有 技术 背景 的 亲友 只 能 读 慌 这 一 部 分 ， 所 以 要 尽量 写 得 
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分 析 网 络 包 占 用 了 很 多 本 应 该 和 家 人 在 一 起 的 时 光 ， 因 此 要 特别 
感谢 他 们 的 理解 和 文 持 。 我 妻子 在 每 天 忙碌 的 工作 之 余 ， 还 要 弥补 我 
的 那 份 亲子 时 间 ， 让 人 小满 重 受到 完美 的 亲情 。 她 也 十 第 一 个 审核 书稿 
的 人 ， 包 括 文字 和 技术 两 方面 ,“ 色 内助” 一 词 已 经 不 足以 形容 她 的 页 
献 了 。 我 父母 分 担 了 很 多 家 性 劳动 ， 否 则 花园 里 早 束 杂 草 丛生。 他 们 
可 能 至 今 还 以 为 我 坐 在 电脑 面前 欧 是 在 赶 稿子 。 

技术 圈 的 很 多 朋友 帮忙 检阅 了 本 书 部 分 章 玉 ， 为 我 挛 把 技术 天 。 
请 给 我 一 次 招待 你 们 吃 大 餐 的 机 会 。 

我 的 老板 从 没有 提出 过 KPI 上 的 要 求 ， 因 此 我 才 有 这 么 多 时 间 研 
完工 作 之 外 的 技术 问题 。 

此 外 还 要 感 山 很 多 读者 长 期 的 疼 励 ， 请 息 我 无 法 一 一 列举 你 们 的 
名 字 。 要 不 钙 你 们 隔 段 时 间 束 催 一 下 ， 以 我 的 拖延 症 不 知道 何 日 才能 
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Wireshark 已 经 用 不 着 我 来 做 广告 了 ， 它 早已 被 多 家 权威 机 构 评 为 
最 住 咒 探 费 ， 从 事 网 络 工作 的 工程 师 都 知道 它 。 即 便 我 如 实地 列举 它 
的 种 种 好 处 ， 都 涉嫌 违反 广告 法 。 这 也 许 束 是 我 的 上 一 本 书 
《Wireshark 网 络 分 析 束 这 么 人 简单》 得 以 多 次 重印 的 原因 ， 是 神 紫 忌 会 
流行 的 。 读 着 的 评价 也 超 乎 我 的 想象 ， 随 手 复制 两 条 书评 过 来 满足 一 
下 我 的 虚 采 心 : 

“这 本 书 陪 了 我 几 个 深夜 。 没 有 大 部 头 的 催眠 和 艰 涩 ， 每 一 节 都 精炼 易 读 ， 和 咖啡 一 样 令 
人 上 疗 。 我 是 网 络 小 新 人 ， 但 是 不 觉得 特别 难 ， 很 容易 顺 下 来 。 里 面 很 多 干货 ， 厚 积 
都 是 实际 环境 中 的 情况 。 畅 快 淋 演 读 完 大 呼 不 过 壮 ， 搜 了 一 下 作者 就 这 一 本 书 。 遗 
亚马逊 读者 

“这 本 书 是 我 2014 年 读 过 的 10 本 好 书 之 一 ， 如 果 说 我 对 这 本 书 有 什么 不 满 的 话 ， 就 只 有 一 
个 : 书写 落 了 ， 意 犹 未 尽 ， 读 着 完全 不 过 壮 呀 呀 呀 。 或 许 这 本 书 浅显 易 慌 、 幽 默 风趣 的 语言 
风格 让 你 在 无 障碍 阅读 的 同时 ， 会 让 你 有 一 种 这 书 太 浅 、 适 合 初学 者 的 感觉 但 是 这 本 书 实 
际 上 是 越 读 越 有 味道 ， 我 就 读 了 好 几 次 。” 


一 豆 六 读者 

既然 有 这 么 多 人 喜欢 ， 我 有 什么 理由 不 再 写 一 本 呢 ? 于 是 就 有 了 

这 本 新 书 。 虽 然 我 在 写 稿 这 件 事 情 上 的 拖延 省 不 亚 于 洗 碗 ， 不 过 读者 
们 的 鼓励 显然 起 了 作用 ， 最 后 收 笔 时 间 只 比 原 计 划 晚 了 6 个 月 。 和 老 读 
者 们 期 望 的 一 样 ， 它 是 上 一 本 书 的 延续 ， 尤 其 旦 在 写作 风格 上 “。 不 同 
之 处 在 于 这 一 本 不 再 着 重 分 析 基 础 协议 ， 而 更 专注 于 解决 现实 问题 。 


另外 ， 考 虑 到 现在 手机 上 网 日 趋 流行 ， 本 书 也 增加 了 一 些 手 机 App 的 
内 容 ， 相 信 读 者 会 喜欢 。 

束 如 我 常 在 培训 课 上 所 讲 的 ， 学 会 Wireshark 这 个 软件 只 需要 几 个 
小 时 ， 掌 握 一 个 网 络 协议 也 用 不 了 几 天 ， 而 养 成 解决 问题 的 思路 却 需 
要 经 年 累 月 的 练习 和 思考 。 本 书 正 提供 了 很 多 练习 和 思考 的 机 会 ， 本 
书 30 多 篇 文章 ， 几 乎 都 用 了 Wireshark 来 分 析 网 络 包 。 我 希望 每 一 篇 都 
能 让 读者 产生 这 样 的 感触 :“ 啊 ， 原 来 Wireshark 还 可 以 这 样 用 ! * 读 完 
整 本 书 ， 上 自然 而 然 会 形成 看 包 的 习惯 和 思维 方式 。 

本 书 组 织 结构 

就 像 时 尚 女郎 每 天 都 在 看 包 包 一 样 ， 我 也 每 天 都 在 看 包 。 看 到 有 
趣 又 有 价值 的 ， 就 会 记录 下 来 ， 久 而 久之 就 形成 了 这 本 书 。 因 此 它 有 
别 于 包罗 万 象 的 网 络 教材 ， 而 更 像 一 个 技术 博客 的 合集 。 

全 书 根据 素材 来 源 可 分 为 四 个 部 分 。 

第 一 部 分 的 选材 来 自 老 读者 的 咨询 ， 相 信 很 有 代表 性 ， 说 不 定 其 
他 读者 也 会 遇 到 。 

《Linux 为 什么 卡 住 了 》 分 析 了 登录 Linux 时 卡 顿 10 秒 钟 的 现象 。 
虽然 我 是 Linux 领 域 的 菜鸟 ， 但 是 仍然 可 以 用 Wireshark 发 现 原因 并 解决 
它 o 

.《 像 福尔摩斯 一 样 思考 》 讲 述 的 是 如 何 根据 网 络 包 中 的 蛛 丝 马 
迹 ， 找 到 被 人 为 掩盖 的 线索 。 自 己 从 网 络 包 推理 出 来 的 东西 ， 往 往 比 
对 方 提供 的 文档 更 可 靠 。 

.《 一 篇 关于 VMware 的 文章 》 介 绍 了 一 位 读者 在 VMware 知识 库 发 
现 的 文章 。 我 们 纯粹 依靠 协议 分 析 ， 找 到 了 这 篇 文章 的 真正 内 洱 ， 最 
后 再 用 Wireshark 看 包 加 以 确认 。 

《来 点 有 深度 的 》 是 在 上 一 篇 的 基础 上 ， 通 过 发 散 思 维 ， 疝 读者 
“灌输 ”了 一 些 相 关 的 TCP 知 识 。 个 人 觉得 TCP 协 议 理解 到 这 个 深度 束 
足够 应 付 大 多 数 性 能 问题 了 。 


.《 三 次 握手 的 小 知识 》 是 应 某 论坛 网 友 的 要 求 而 写 的 TCP 握 手 科 
普 ， 分 至 了 一 些 用 Wireshark 来 处 理 握手 问题 的 小 经 验 ， 顺 便 演示 了 
“SYN flood” 攻 击 的 网 络 包 。 

《被 误解 的 TCP》 淤 清 了 被 读者 广泛 误解 的 两 个 TCP 概 念 ， 比 较 
了 Linux、Windows 和 安 卓 手机 的 不 同 Ack 频 率 。 

《最 经 典 的 网 络 问题 》 是 我 近年 遇 到 过 的 最 经 典 的 案例 了 。 虽 然 
很 多 年 前 就 听 说 过 Nagle 算 法 过 到 延迟 确认 会 出 问题 ,但 是 在 现实 中 还 
是 第 一 次 遇 到 ， 赶 紧 记 录 下 来 。 

《为 什么 于 了 单子 ? 》 讲 述 了 一 位 销售 朋友 的 遭遇 ， 说 明 用 
Wireshark 有 助 于 发 现 产品 的 不 足 ， 并 且 找 到 改进 之 处 。 如 采 能 
Wireshark 分 析 上 自家 产品 与 竞争 对 手 产 品 的 网 络 包 ， 一 定 能 找到 不 少 差 
别 ， 从 而 改进 销售 策略 。 

.《 受 损 的 帧 2》 分 析 了 因为 硬件 等 原因 导致 帧 损坏 ， 从 而 在 
Wireshark 上 体现 出 的 奇怪 症状 。 事 情 往往 没有 表面 上 看 到 的 那么 简 
单 o 

.《 虚 怀 一 场 》 是 因为 一 位 眼 尖 的 读者 发 现 了 我 书 中 的 一 处 “错误 ” 

(或 者 可 以 说 是 TCP 的 一 个 bug) ， 后 来 研究 了 很 久 才 发 现 是 虚惊 一 
场 ， 不 过 排查 过 程 还 是 很 值得 分 享 的 。 这 位 读者 还 从 “作者 人 简介 ”的 照 
片 中 ， 看 到 我 手 上 的 《TCP/P 详 解 卷 1: 协议》 是 影印 版 ， 然 后 特意 从 
美国 帮 有 我 寄 来 了 一 本 原版 书 。 再 次 表示 感谢 ! 

《NTLM 协 议 分 析 》 是 这 部 分 唯一 的 基础 协议 介绍 ， 据 说 NTLM 
在 中 国 用 得 还 很 多 ， 所 以 才 特 意 写 了 一 篇 。 

《Wireshark 的 提示 》 收 集 了 读者 感 兴趣 的 很 多 Wireshark 提 示 信 
息 。 文 中 不 但 介绍 了 每 一 个 提示 信息 的 意义 ， 还 分 析 了 其 产生 的 原 
因 ， 硕 望 让 读者 能 够 知 其 所 以 然 。 

第 二 部 分 是 我 自己 在 工作 中 直到 的 网 络 问题 。 这 部 分 讲 得 最 细 、 
最 深 ,问题 本 映 也 最 复杂 。 在 阅读 这 一 部 分 时 ， 可 能 要 多 论点 时 间 。 


.《 书 上 错 了 吗 ? 》 解 释 了 为 什么 对 于 同一 个 TCP 连 授 ， 在 两 端 抓 
到 的 网 络 包 顺序 是 不 同 的 。 明 日 了 这 一 点 才能 理解 后 面 两 篇 的 内 容 。 

《计算 “在 途 字 市 数 ”》 介 绍 了 如 何 从 网 络 包 中 计算 “已 经 发 送 但 
未 被 确认 ”的 数据 量 。 不 用 害怕 数学 ， 人 简单 的 加 减法 就 够 用 了 。 

《估算 网 络 拥塞 点 》 在 前 两 篇 的 基础 上 ， 提 供 了 一 个 估算 网 络 拥 
塞 点 的 方法 。 掌 握 了 这 个 技能 ， 此 后 再 优化 TCP 性 能 时 就 胸有成竹 
了 o 

《顺便 说 说 LSO》 讲 的 是 现在 越 来 越 普 志 的 Large Segment 
Offload。 在 估算 拥塞 点 的 时 候 很 可 能 会 被 LSO 所 干扰 ， 因 此 我 特意 为 
它 写 了 一 入 

“*:《 熟 读 RFC》 分 析 了 一 个 顾 为 严 手 的 性 能 问题 ， 即 使 擅长 
Wireshark 也 很 难 解决 ， 向 大 家 展示 了 熟悉 RFC 的 重要 性 。 

`.《 一 个 你 本 该 能 解决 的 问题 》 用 Wireshark 分 析 了 一 个 UDP 导致 的 
性 能 问题 ， 从 本 质 上 分 析 UDP 和 TCP 的 差别 。 这 一 篇 我 在 微 博 上 发 
过 ， 还 引发 了 一 场 不 小 的 讨论 。 

`.《 几 个 关于 分 片 的 问题 》 其 实 是 上 一 篇 的 后 续 。 很 多 读者 看 到 
UDP 包 被 分 片 之 后 出 现 了 性 能 问题 ， 所 以 对 分 片 很 感 兴趣 ， 问 了 不 少 
问题 。 

`.《MTU 导 致 的 斐 剧 》 分 享 了 几 个 MTU 配 置 出 问题 而 导致 的 事 
故 。 这 类 问题 其 实 很 多 见 的 ， 尤 其 是 对 于 实施 和 运 维 人 员 来 说 。 

《迎刃而解 》 有 是 来 自 一 个 运 维 部 门 鸭 技术 问题 ， 相 当 隐 蔽 而 且 详 
异 ， 最 终 在 Wireshark 的 辅助 下 迎刃而解 。 

《县 伦 一 现 的 协议 》 回 忆 了 一 个 我 曾经 文 持 过 的 协议 。 今 天 才学 
习 它 可 能 没有 实际 意义 ， 但 是 其 理念 和 创意 还 是 值得 借鉴 的 。 当 你 对 
一 个 协议 了 解 到 一 定 程度 时 ， 肯 定 也 会 有 改造 它 的 想法 。 

.《 另 一 种 流 控 》 介 绍 的 是 Pause Frame 《暂停 帧 ) 流 控 。 有 别 于 
TCP 的 “ 端 到 端 ? 流 控 ， 它 是 “点 到 点 ?的 ， 在 有 些 场 合 很 好 用 。 


《过 犹 不 及 》 分 享 了 一 个 多 线程 传输 的 案例 ， 说 明 不 是 增加 连接 
数 克 一 定 能 提高 性 能 ， 有 时 候 甚 至 有 负面 效果 。 

《治疗 强迫 证 》 演 示 了 如 何 用 Wireshark 人 研究 文本 编辑 软件 的 工作 
方式 。 也 许 这 类 软件 不 是 你 的 兴趣 所 在 ， 但 是 可 以 举一反三 ， 用 相同 
的 方式 研究 其 他 软件 。 

《技术 与 工龄 》 算 是 半 篇 技术 文章 。 除 了 介绍 Window Scale 这 个 
技术 点 ， 还 希望 每 个 人 都 能 正视 工龄 ， 善 待 新 人 。 

《一 个 面试 建议 》 只 是 分 享 面试 经 验 ， 完 全 无 关 技 术 。 文 章 写 得 
很 不 严肃 ， 目 的 是 让 读者 休息 一 下 ， 乐 一 乐 。 

《如 何 科学 地 推 芭 责 任 》 不 是 想 把 你 “ 教 坏 ”， 而 是 分 享 了 如 何在 
技术 上 划分 责任 。 如 果 你 是 乙方 工程 师 ， 肯 定 会 需要 的 。 

第 三 部 分 的 选材 是 日 常生 活 中 的 抓 包 ， 包 括 手机 App。 在 未 来 一 
两 年 ， 可 能 会 有 越 来 越 多 的 人 去 抓 手 机 上 的 包 ， 因 为 用 得 多 了 ， 问 题 
也 会 跟着 增加 。 

.《 假 宽 市 真相 》 本 是 央视 某 一 期 和 目的 名 字 ， 说 测速 软件 “有 明 
显 的 设计 缺陷”。 我 用 Wireshark 进 行 了 验证 ， 结 果 如 何 昵 ? 读 了 全 文 
就 知道 了 。 

《手机 抓 包 》 讲 解 的 是 如 何在 家 里 搭建 适合 抓 手 机 包 的 WiFi 环 
境 。 如 采 你 经 常 需要 抓 手 机 上 的 包 来 研究 ， 相 信 我 ， 是 该 改造 一 下 家 
里 的 网 络 了 。 

.《 微 博 为 什么 会 卡 》 分 析 了 微 博 在 WiFi 环 境 下 经 党 卡 顿 的 问题 ， 
最 后 找 出 来 的 原因 竟然 是 DNS。 本 文 对 很 多 App 的 优化 有 借鉴 作用 。 

《寻找 HttpbDNS》 讲 述 了 一 个 “失败 ”的 探索 过 程 ， 因 为 到 最 后 都 
没有 找到 想 要 的 包 。 不 过 失败 本 和 喘 也 有 价值 ， 因 为 我 们 知道 了 真相 不 
过 如 此 。 

.《 谁 动 了 我 的 网 络 》 详 细 地 讲解 了 被 支持 的 网 络 包 有 什么 特征 ， 
以 及 如 何在 Wireshark 中 找到 它们 。 下 一 次 你 怀疑 目 家 网 络 被 支持 时 ， 


束 可 以 抓 一 个 包 目 己 分 析 了 。 

《一 个 协议 的 进化 》 介 绍 的 是 当前 HTTP 1.1 在 性 能 上 的 落后 之 
处 ， 以 及 可 能 改进 的 空间 。 可 惜 现 在 HITP 2 的 包 还 不 容易 抓 下 ， 否 则 
我 们 还 可 以 增加 一 些 内 容 。 

《假装 产品 经 理 》 分 析 了 在 微 博 发 图 片 的 网 络 包 ， 我 们 可 以 从 中 
看 到 它 的 压缩 比例 、 上 传 行为 、CDN 服 务 两 等。 不 用 派 卧 的 去 新 浪 ， 
残 可 以 侦察 到 不 少 “ 机 密 ”。 

*:《 目 学 的 守门 》 也 无 关 技 术 ， 只 是 分 享 了 本 人 的 学 习 经 验 ， 和 希望 
对 新 人 有 些 参考 价值 。 

第 四 部 分 的 内 容 很 少 ， 却 花费 了 我 不 少时 间 ， 因 为 写 的 是 两 个 项 
目 / 产 品 。 

《打造 目 己 的 分 析 工 具 》 介 绍 了 我 日 己 打 造 的 一 个 性 能 
站 ， 让 大 家 体验 一 下 量 身 定制 的 工具 有 多 好 用 。 本 文 也 分 享 了 
程 的 一 些 经 验 。 

《一 个 创业 点 子 》 讲 的 是 我 曾经 想 做 的 一 个 网 络 加 速 器 。 里 面 知 
识 点 还 古 挺 多 的 ， 也 适合 用 Wireshark 来 研究 。 

你 可 能 会 问 的 一 些 问 题 

1. 阅读 此 书 需 要 什么 基础 ? 

只 需要 具备 网 络 常识 ， 比 如 在 学 校 里 上 过 网 络 课 或 者 考 过 CCNA 
瓯 够 了 。 如 采 读 过 《Wireshark 了 网 络 分 析 束 这 么 简单 》 是 最 好 的 ， 会 觉 
得 衔接 顺畅 。 对 于 缺乏 网 络 基础 的 Wireshark 用 户 ， 建 议 先 阅读 Richard 
Stevens 的 《TCP/IP 详 解 卷 1: 协议 》。 有 英文 好 的 读者 可 以 通过 
http://www.tcpipguide.com/free/index.htm 页 面 免 费 阅 读 《The TCP/IP 
Guide》 一 书 ， 里 面 的 插图 画 得 尤其 好 。 由 于 读 人 免费 书籍 很 难 坚持 下 
去 ， 你 可 以 点 击 页 面 下 方 的 Donate 按 钮 给 作者 捐 球 ， 由 此 增加 进一步 
学 习 的 功力 。 

2. 本 书 的 选材 为 何如 此 广泛 ? 


分 析 网 
开发 过 


我 写 这 本 书 是 为 了 让 读者 学 有 所 获 ， 因 此 选材 也 从 读者 的 兴趣 点 
出 发 。 比 如 现在 流行 手机 上 网 ， 因 此 我 增加 了 这 部 分 的 内 容 ， 又 比如 
技术 圈 正 在 热 议 HttpDNS， 所 以 我 束 去 做 了 一 系列 实验 ..….….…. 不 同 读者 
的 关注 点 肯定 会 有 所 不 同 ， 如 果 某 一 篇 的 话题 不 是 你 感 兴趣 的 ， 直 接 
跳 过 也 不 影响 后 面 的 阅读 。 

3. 为 什么 我 觉得 有 些 内 容 太 简单 了 ? 

人 们 读书 时 都 会 有 这 样 的 反应 读 到 自己 不 懂 的 内 容 时 ， 束 会 
觉得 高 大 上 ; 读 到 目 己 擅长 的 领域 时 ， 又 会 觉得 太 人 简单 。 这 就 是 为 什 
么 有 些 作者 喜欢 把 书写 得 很 玄 平 ， 然 而 我 的 风格 恰恰 相反 ， 会 尽 可 能 
地 把 复杂 的 问题 简单 化 。 我 的 技术 培训 也 是 坚持 这 样 的 风格 ， 会 假设 
所 有 听众 都 是 刚 毕 业 的 文科 妹子 ( 咽 ， 这 样 也 会 使 我 的 心情 好 一 
Ej 

4. 为 什么 没有 随 书 光盘 ? 

我 也 希望 能 把 这 本 书 里 的 网 络 包 都 共享 出 来 ， 但 由 于 大 多 是 在 客 
户 的 生产 环境 中 抓 到 的 ， 所 以 不 适合 公开 。 毕 竟 从 包 里 能 又 露出 来 的 
安全 隐患 太 多 了 ， 硕 望 读者 能 理解 这 个 杏 囊 。 为 了 方便 阅读 ， 我 已 经 
尽量 把 Wireshark 鹤 图 做 清晰 。 建 议 大 家 在 目 己 的 环境 中 抓 包 分 机 ， 这 
会 比 看 示例 包 更 有 价值 。 

5. 怎样 联系 作者 ? 

如 果 对 书 中 的 内 容 有 疑问 ， 或 者 自己 抓 了 包 却 不 知道 怎么 分 析 ， 
都 可 以 联系 作者 ， 邮 箱 地 址 为 jnpeiman@hotmail.com。 你 也 可 以 在 微 
博 上 @ 林 沛 满 ， 但 不 建议 关注 ， 因 为 他 是 个 整 天 晒 园 艺 图 片 的 话 兽 。 


/Xr 


在 过 去 几 年 中 ， 有 不 少 读者 、 同 事 和 网 友 癌 我 容 询 过 网 络 问 题 ， 
其 中 大 部 分 都 记录 在 和 案 。 我 一 直 把 这 些 案例 视 为 珍 贯 的 财富 ， 因 为 既 
真实 又 有 广泛 的 代表 性 ， 比 我 目 己 在 实验 宇 中 “制造 "出 来 的 好 多 了 。 
本 书 从 中 选择 了 最 经 典 的 部 分 ， 和 希望 读者 会 感 兴趣 。 如 有 果 你 在 工作 或 
生活 中 明 到 网 络 问题 ， 也 欢迎 抓 个 包 来 找 我 分 析 。 


Linux 为 什 和 ? 


到 今天 为 止 ， 已 经 有 5 位 读者 向 我 求助 过 这 个 问题 了 。 症 状 请 看 图 
1， 他 们 通过 SSH 登 录 Linux 服 务 器 时 ， 输 完 用 户 名 就 卡 住 了 ， 要 等 待 10 
秒 钟 才 提示 密码 输入 。 这 究竟 是 什么 原因 导致 的 呢 ? 其 实 我 也 是 Linux 
菜鸟 ， 虽 然 尝试 过 搜索 “ssh hang” 等 关键 词 ， 但 是 没 找到 相关 信息 。 
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图 1 

10 秒 钟 的 时 间 并 不 算 长 ， 吃 个 暮 片 喝 口 咖啡 就 过 去 了 “。 但 是 作为 
强迫 证 患者 ， 我 还 是 容 不 得 它 的 存在 ， 因 此 便 决 定 写 篇 文章 ， 向 大 家 
演示 一 下 怎样 用 Wireshark 一 步 步 解 决 这 个 问题 。 

首先 是 抓 包 ， 步 又 如 下 。 

1. 在 Linux 服 务 絮 上 启动 抓 包 。 

2. 从 笔记 本 SSH 到 Linux 服 务 器 ， 输 入 用 户 名 并 回 车 。 

3. 等 待 10 秒 左右 ， 直 到 登录 界面 提示 输入 密码 。 

4. 停止 抓 包 。 

这 样 就 可 以 得 到 一 个 涵盖 该 现象 的 网 络 包 了 。 一 般 在 实验 室 中 没 
有 干扰 流量 ， 不 用 过 滤 也 可 以 分 析 ， 不 过 我 们 最 好 在 做 实验 时 就 养 成 
过 滤 的 习惯 ， 以 适应 生产 环境 中 抓 到 的 包 。 因 为 我 们 是 通过 SSH 协 议 登 
录 的 ， 所 以 可 以 直接 用 ssh" 来 过 滤 ， 如 图 2 所 示 。SSH 包 都 是 加 密 了 
的 ， 因 此 我 们 看 不 出 每 个 包 代表 了 什么 意思 ， 不 过 这 并 不 影响 分 析 。 
从 图 2 中 可 以 看 到 ，21 号 包 和 25 号 包 之 间 恰 好 就 相隔 10 秒 。 


图 2 


Fiter ssh [= | Expression.. Clear Apply Save 
No. Time Source _ Destination Protocol Info 
10 0.019267 Laptop Linux_server SSHv2 Client: Diffie-Hellman Group Exchange Request (01d) 
11 0.023411 Linux_server Laptop SSHV2 Server: Diffie-Hellman Group Exchange Group 
12 0.128382 Laptop Linux_server ssHv2 Client: Diffie-Hellman Group Exchange Init 
14 0.180761 Linux_server Laptop SSHVv2 Server: Diffie-Hellman Group Exchange Reply, New Keys 
15 0.344019 Laptop Linux_server SSHv2 Client: New Keys 
17 0. 344116 Laptop Linux_server ssHv2 Client: Encrypted packet (len=52) 
19 0.344196 Linux_server Laptop SSsHv2 Server: Encrypted packet (len=52) 
21 1.661846 Laptop Linux_server SSHv2 Client: Encrypted packet (len=68) 
25 11.664153 Linux_server Laptop SSHv2 Server: Encrypted packet (len=1460) 
26 11.664160 Linux_server Laptop SSHVv2 Server: Encrypted packet (len=100) 
28 11.667277 Laptop Linux_server SsHv2 Client: Encrypted packet (len=100) 
30 11.668867 Linux_server Laptop SSHV2 Server: Encrypted packet (len=84) 
34 13.548907 Laptop Linux_server SSHv2 Client: Encrypted packet (len=296) 
35 13.550799 Linux_server Laptop SSHV2 Server: Encrypted packet (len=36) 
36 13.551555 Laptop Linux_server ssHv2 Client: Encrypted packet (len=68) 
37 13.553077 Linux_server Laptop SSHv2 Server: Encrypted packet (len=52) 


这 两 个 包 之 间 所 发 生 的 事件 ， 可 能 就 是 导致 这 个 现象 的 原因 。 于 
是 我 再 用 “frame.number>21 尺 尺 frame.number<25” 过 滤 ， 结 果 如 图 3 所 


人 N° 
Fiter | frame.number > 21 && frame.number < 25 图 Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
22 1.662507 Linux_server DNS_Server DNS standard query Oxcbfe PTR 23.200.32.10.in-addr.arpa 
23 1.701128 Linux_server Laptop Tr 22~57579 [ACK] Seq=2498 Ack=1381 Win=8544 Len=0 
24 6.661771 Linux_server DNS_Server DNS standard query Oxcbfe PTR 23.200.32.10.in-addr.arpa 


图 3 


从 图 3 中 可 以 看 到 ，Linux 服 务 器 当时 正 忙 着 向 DNS 服 务 器 查询 


10.32.200.23 的 PTR 记 录 ( 即 反 向 解析 ) ,试图 获得 这 个 IP 地 址 所 对 应 
的 域名 。 该 卫 属 于 我 们 测试 所 用 的 笔记 本 ， 但 由 于 DNS 服务 器 上 没有 
它 的 PTR 记 录 ， 所 以 两 次 查询 都 等 了 5 秒 钟 还 没 结果 ， 总 共 当 费 了 10 秒 
钟 。 

我 们 由 此 可 以 推出 ， 这 台 Linux 服 务 器 在 收 到 SSH 访 问 请 求 时 ， 会 
先 查 询 该 客户 端 卫 所 对 应 的 PTR 记 录 。 假 如 经 过 5 秒 钟 还 没有 收 到 回 
复 ， 就 再 发 一 次 查询 。 如 果 第 二 次 查询 还 是 等 了 5 秒 还 没 回 复 ， 就 彻底 
放弃 查询 。 我 们 甚至 可 以 进一步 猜测 ， 如 果 DNS 查询 能 成 功 ， 束 不 用 
白 等 那 10 秒 钟 了 。 

为 了 验证 这 个 猜测 ， 我 在 DNS 服 务 絮 中 添加 了 10.32.200.23 的 PTR 
记录 ， 如 图 4 所 示 ， 然 后 再 次 登录 。 


史 dnsmgmt - [DNSs\DC1\Reverse Lookup Zones\10.32.200.x Subnet] 
昌 Eile Bction Yiew ‘Window Help 
和 小 | 舌 | 四 | 话 囊 区 | 贸 困 | 目 自 全 


+ Ey nas,com 


Dd Reverse Lookup zones 


-EN 10,32,106,x Subnet 
EY 10,32,16,x Subnet 
BH 10,32,190,x Subnet 
{Ej 10.32,23,x Subnet 
司 10,71,34,x Subnet 
加 | 10,32,200,x Subnet 
圆 Event Yiewer 


dcl,nas,com， 
dc2,nas,com， 
[2], dcl,nas,com,, hostmas,,， 


Name 5erver (N5) 
Name 5erver (N5) 
Start of Authority (SOA) 


same as parent folder) 
same as parent folder) 
目 (same as parent folder’ 


一 次 果然 立即 登录 进去 了 。 从 图 5 的 Wireshark 截 屏 可 见 ， 


图 4 


ee | 


DNS 查 


种 下 的 所 以 21 号 包 和 26 号 包 之 间 几 乎 是 没有 时 间 停 顿 的 。 


Time Source Destination Protocol Info 
7 0.354656 laptop.nas.com Linux_server SSHv2 Client: Encrypted packet (len=52) 
18 0.354689 Linux_serVver laptop. nas. com TCP 22-58426 [ACK] Seq=2446 Ack=1313 Win=8544 Len=0 
19 0.354756 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=52) 
20 0.562055 laptop.nas.com Linux_server TCP 58426-22 [ACK] seq=1313 Ack=2498 Win=65536 Len=0 
21 1.444473 laptop.nas.com Linux_server SSHv2 Client: Encrypted packet (len=68) 
22 1.445674 Linux_server DNS_Server DNS standard query 0xda56 PTR 23.200.32.10. in-addr.arpa 
23 1.445870 DNS_Sserver Linux_server DNS standard query response Oxda56 PTR laptop.nas.com 
24 1.446147 Linux_server DNS_Server DNS standard query 0xla68 A laptop.nas.com 
25 1.446319 DNS_server Linux_server DNS standard query response 0xla68 A 10.32.200.23 
26 1.455106 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=1460) 
27 1.455116 Linux_server laptop. nas. com SSHv2 Server: Encrypted packet (len=100) 
28 1.455806 laptop.nas.com Linux_server TCP 58426-22 [ACK] Seq=1381 Ack=4058 Win=65536 Len=0 
29 1.458199 laptop.nas.com Linux_server SsSHv2 Client: Encrypted packet (len=100) 
30 1.459701 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=84) 
图 5 
\ 2 公交 
明白 了 DNS 查 询 就 是 问题 的 起 因 ， 接 下 来 就 知道 怎么 进一步 研究 
55 39 人 和. Ny > 日 .上 2 Sy | 日 
。 只 要 在 Google 搜 索 “ssh dns 页 出 来 的 链接 都 是 天 于 这 个 问题 


的 。 随 便 挑 几 篇 阅读 一 
研究 远 了 。 原 来 这 个 


认 配 置 是 这 样 的 : 
[root@Linux_Server~]#cat/etc/ssh/sshd_config|grep-i usedns 
#UseDNS yes 
改 成 下 面 这 样 束 可 以 解决 了 ， 不 用 去 动 DNS 服 务 絮 上 的 配置 : 
[root@Linux_Server~]#cat/etc/ssh/sshd_config|grep-i usedns 

UseDNS no 


下 


束 连 我 这 样 的 Linux 初 学 者 都 能 把 这 个 问题 
行为 是 定义 在 “/etc/ssh/sshd_config” 文 件 中 的 ， 默 


我 经 第 说 技能 比 知 识 更 重要 ， 这 就 是 例子 之 一 。 学 会 了 使 用 
Wireshark， 其 他 知识 也 会 跟着 来 的 。 


晶 尔 摩 斯 一 样 思 


有 位 读者 在 豆 办 上 评论 我 的 上 一 本 书 ， 说 有 阅读 侦探 小 说 的 感 
觉 。 我 对 此 并 不 觉得 惊讶 ， 因 为 用 Wireshark 排 查 问题 ， 和 侦探 破案 的 
思路 是 一 致 的 。 神 探 福尔摩斯 的 破案 秘诀 是 “ 漳 因 推理 一 一 和 爷 观 察 所 
有 细 证 ， 比 如 鞋 根 上 的 泥 疙 净 甚 至 烟灰 ; A 
接着 创 去 各 种 不 可 能 ， 最 后 剩 下 的 “无 论 多 么 难以 置信 ， 肯 定 没 锯 。” 
用 Wireshark 分 ) 析 网 络 包 时 也 类 似 ， 我 们 先 要 在 网 络 包 中 守 找 各 种 线 
索 ， 然 后 根据 网 络 协议 作出 推理 ， 接 着 人 刨 去 人 为 《有意 或 无 意 ) 掩盖 
的 证 据 ， 才 能 得 到 最 后 的 真相 。 盛 其 是 和 保密 机 构 打 交道 的 时 候 ， 
程 师 进 不 了 机 房 ， 文 档 也 不 能 公开 ， 所 以 一 切线 索 只 能 目 己 在 包 
找 ， 感 觉 束 更 像 破 案 了 。 

我 最 近 帮 一 位 读者 解决 的 问题 束 非 第 典型 。 他 供职 的 机 构 内 部 网 
站 有 时 候 会 发 生 诡异 的 现象 ， 比 如 Web 服 务 器 的 端口 号 会 随机 发 生变 化 
(具体 症状 就 不 多 讲 了 ， 和 本 文 关 系 不 大 ) 。 后 来 做 了 排查 ， 把 客户 
疝 和 Web 服 务 右 直 连 ， 问 题 束 消 失 了 ， 确 认 了 Web 上 服务器 和 客户 端 都 没 
有 问题 。 难 道 根 本 原因 残 出 在 网 络 路 径 上 了 ? 可 征管 理 员 又 声称 网 络 
拓扑 非常 简单 ， 不 会 出 问题 的 。 见 图 1， 客 户 端 和 Web 服 务 右 在 不 同 的 
子 网 里 ， 中 间 由 一 个 路 由 瑚 转发 。 


客户 端 路 由 器 Web 服 务 器 


图 1 
赁 我 的 经 验 ， 这 个 网 络 拓扑 的 确 简单 到 没有 出 问题 的 可 能 。 可 是 
经 到 了 山 穷 水 尽 的 地 步 了 ， 只 好 抓 包 试 试 。Web 服 务 器 不 允许 我 们 登 
录 ， 所 以 只 能 在 客户 端 抓 ， 更 糟糕 的 是 抓 包 时 那个 诡异 的 现象 并 没有 
发 生 。 你 一 定 会 纳 四 ， 正 常 状况 抓 的 包 有 什么 看 头 啊 ?9 人 在 走投无路 
的 时 候 ， 要 求 都 是 很 低 的 ， 能 抓 到 一 点 算 一 点 。 图 2 就 是 抓 到 的 包 ， 看 
起 来 一 切 都 很 正常 前 3 个 包 是 三 次 握手 ， 接 着 客户 端 发 了 个 HITP 
GET 请 求 ， 服 务 器 也 确认 收 到 了 。 


No. Time Source Destination Protocol Info 
1 0.000000000 ”client Web_server TCP 3106-80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_I 
2 0.004205000 Web_server Client TCP 80~3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 
3 0.004212000 Client Web_server TCP 3106-80 [ACK] Seq=1 Ack=l Win=65536 Len=0 
4 0.162915000 client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80~3106 [ACK] seq=1 Ack=385 Win=30336 Len=0 
图 2 


既然 表面 上 都 是 好 的 ， 我 们 再 看 看 每 个 包 的 详细 信息 。1 号 包 的 详 
i 
地 址 属于 默认 网 天 。 将 包 交 给 默认 网 天 是 合理 的 ， et a em 
一 个 子 网 中 ， 需 要 路 由 转发 。 也 就 是 说 ， 从 1 号 包 中 没有 发 现任 何 异 


首 O 
No， Time Source Destination Protocol Info 
1 0.000000000 Client Web_server TCP 3106-~80 [SYN] Seq=0 Win=65535 Len=0 MSS=14 
2 0.004205000 Web_server Client TCP 80-~3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 L 
3 0.004212000 Client Web_server TCP 3106~80 [ACK] Seq=1 Ack=l Win=65536 Len=0 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80-3106 [ACK] Seq=1 Ack=385 Win=30336 Len= 
< 


'm[Erame 下 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 
由 Ethernet II, Src: |00:50:56:8a:25:52 (00:50:56:8a:25: 52), 2:bd:88 


日 Internet ED Version 4, src: Client ( 192.168.111.111 ) ， We SE (192.168.222.222) 


图 3 
再 看 看 图 4 的 2 号 包 详 情 。 这 个 包 让 人 眼前 一 亮 ， 信 息 量 实在 太 大 
了 。 在 阅读 下 面 的 文字 之 前 ， 建 议 你 自己 先 在 图 中 找 找 亮点 。 


No. Time Source Destination Protocol Info 
1 0.000000000 “Client Web_server TCP 3106~80 [SYN] Seq=0 Win=65535 Len=0 MSS= 
2 0.004205000 Web_server Client TCP 80-3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 
3 0.004212000 Client Web_server TCP 3106-80 [ACK] Seq=1 Ack=1 Win=65536 Len= 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80-3106 [ACK] Seq=1 Ack=385 Win=30336 Le 
< 
| 


HM 


田 [Ecane 2 66 bytes on _ wire (528 bits), 66 bytes captured (528 bits) on interface 0 
四 Ethernet II, Src: to00:10:f3:27:61:86| (00:10:f3:27:61:86), Dst: |00:50:56:8a:25:52| (00:50:: 


日 INternet Protocol Version 4, src: Web_server (192.168.222.222), Dst: Client ( 192.168.111.111 
Version: 4 


Header Length: 20 bytes 
由 Differentiated services Field: Ox00 (DsCP Ox00: Default; 


; ECN: Ox00: Not-ECT (Not ECN-C 
Total Lengqth: 52 
四 Flags: Ox02 (Don t Fragment) 


Fragment offset: 0 


图 4 

首先 这 个 包 竟 然 是 从 MAC 地 址 00:10:f3:27:61:86 发 过 来 的 ， 而 不 是 
之 前 提 到 的 默认 网 关 c0:62:6b:e2:bd:88。 我 不 知道 这 个 MAC 地 址 属于 什 
么 设备 ， 但 这 至 少 说 明 2 号 包 和 1 号 包 走 了 条 不 一 样 的 路 径 。 再 看 其 
Time to live (TTL) 居然 是 64， 理 论 上 经 过 一 次 路 由 的 包 ，TTIL 应 该 减 
去 1， 变 成 63 才 对 。 根 据 这 两 条 信息 ， 可 以 推测 管理 员 提 供 的 拓扑 图 有 
误 。 真 正 的 网 络 包 流 向 应 该 接近 图 5， 即 客户 端 发 出 去 的 包 是 经 过 路 由 
的 ， 而 Web 服 务 器 发 过 来 的 包 没 经 过 路 由 。 


全 
PAY 一 
客户 端 Web 服 务 器 


图 5 

其 实 到 这 里 就 可 以 去 找 管理 员 说 理 了 ， 不 过 别 急 ， 继 续 往 下 看 。 
到 了 图 6 的 第 5 号 包 ， 发 现 Identification 竟 然 是 49031， 而 同样 是 来 自 Web 
服务 器 的 2 号 包 〈 见 图 4) 中 ，Identification 却 是 0。 一 般 发 出 
Identification 为 0 的 机 器 永远 都 发 0， 不 会 一 下 子 跳 到 49031。 也 就 是 
说 ， 其 实 2 号 包 和 5 号 包 是 两 台 不 同 的 设备 发 出 来 的 ， 这 意味 着 在 Web 服 
务 器 和 客户 端 之 间 ， 可 能 存在 一 台 设 备 在 代理 三 次 握手 ， 而 能 够 代理 
握手 的 设备 很 可 能 是 应 对 Syn flood 攻 击 的 防火 墙 。 


No, Time Source Destination Protocol Info 
1 0.000000000 ”client Web_server TCP 3106-~80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 W 
2 0.004205000 Web_server Client TCP 80-3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 
3 0.004212000 Client Web_server TCP 3106-80 [ACK] Seq=1 Ack=1 Win=65536 Len=0 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80-~3106 [ACK] Seq=1 Ack=385 Win=30336 Len=0 
| 


II 
[Erame 引 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 
9 Ethernet II, Src: 00:10:f3:27:61:86 (00:10:f3:27:61:86), Dst: 00:50:56:8a:25:52 (00:50:56:8a:2 


Internet Protocol Version 4, src: Web_server (192.168.222.222), Dst: Client ( 192.168.111.111 ) 
Version: 4 


回 田 a 


Header Length: 20 bytes 

田 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable 
Total Length: 40 

田 Flags: Ox02 (Don't Fragment) 


Fragment offset: 0 
Time to live: 64 


图 6 
因此 图 5 的 拓扑 图 还 不 够 准确 ， 应 该 更 正成 图 7 的 样子 。 管 理 员 名 


视 了 这 侣 防火 墙 ， 可 能 就 错过 了 发 现 问题 根源 的 机 会 。 


安 户 庙 防火 墙 Web 服务 器 
图 7 

把 以 上 分 析 反 馈 给 管理 员 之 后 ， 他 果然 通过 MAC 地 址 
00:10:f3:27:61:86 找 到 了 一 台 防 火 墙 。 也 正 是 防火 墙 上 的 一 些 错误 配 


置 ， 导 致 他 们 遇 到 了 那些 诡异 症状 ， 改 正之 后 症状 就 消失 了 。 本 文 的 
目的 是 演示 如 何在 网 络 包 中 寻找 被 掩盖 的 线索 ， 而 不 是 防火 场 知 识 ， 
所 以 吏 不 展开 了 。 


从 头 到 尾 再 复习 一 下 整个 过 程 ， 是 不 是 很 有 当 侦 探 的 感觉 ? 


注意 : 为 了 保护 客户 隐私 ， 本 文 截 图 里 的 了 地 址 和 MAC 地 址 都 被 PS 过 ， 这 就 是 为 什么 有 


一 篇 大 于 VMware 的 X 章 


有 位 读者 在 VMware 的 知识 库 里 找到 一 篇 文章 ， 觉 得 很 像 他 正在 遭 
遇 的 一 个 性 能 问题 ， 便 转发 给 我 确认 。 作 为 好 为 人 师 的 技术 员 ， 我 当 
然 不 能 让 读者 失望 。 

这 篇 文章 大 概 讲 了 这 样 一 件 事 。 

问题 描述 

某 些 iSCSI 存 储 阵 列 在 出 现 网 络 拥 塞 时 人 处理 不 当 ， 会 严重 影响 
VMware 的 读 写 性 能 。 这 和 它们 的 TCP 实 现 方 式 有 关 。 

解决 方式 

在 VMware 和 存储 阵列 上 关闭 延迟 确认 (Delayed ACK) 

VMware 和 iSCSI 存储 阵列 是 什么 ? 我 在 知识 库 里 找到 一 个 网 络 拓 
扑 ， 看 起 来 很 简单 ， 大 概 如 图 1 所 示 。 我 们 无 需 理解 得 很 深 ， 只 要 把 
iSCSI 存储 阵列 当 作 一 台 服 务 器 ， 再 把 VMware 当 作 其 客户 端 融 行 了 ， 
两 者 通过 以 太 网 传输 数据 。 


Ethernet 


iSCSI 存储 阵列 


图 1 

乍 一 看 ， 这 个 “问题 描述 ”与 “解决 方式 ”简直 风 马 牛 不 相 及 。 网 络 拥 
塞 怎么 能 靠 关 闭 延 迟 确 认 来 解决 ? 不 过 出 于 对 VMware 的 一 贯 信任 ， 我 
决定 还 是 好 好 研究 一 下 。 

我 们 先 要 明白 什么 叫 延 迟 确 认 ， 它 可 以 用 一 个 简单 的 例子 来 说 
明 : 在 上 海 的 笔记 本 上 局 动 Wireshark 抓 包 ， 然 后 用 Putty 远 程 登录 一 台 
位 于 悉尼 的 服务 器 。 由 图 2 可 见 ， 在 上 海 发 出 一 个 SSH 请 求 之 后 ， 经 过 
149 上 毫秒 左右 〈 即 1 号 包 和 2 号 包 之 间 的 时 间 差 ) 收 到 了 悉尼 的 回复 ， 这 
是 正常 的 往返 时 间 。 但 是 笔记 本 收 到 回复 之 后 ， 却 没有 立即 确认 ， 而 
是 延迟 了 200 毫 秒 以 上 《〈 即 2 号 包 和 3 号 包 之 间 的 时 间 差 ) 才 确 认 。 


No. Time Source Destination Protocol Info 


1 0.000000 shanghai sydney SSH Client: Encrypted packet (len=52) 

2 0.148774 sydney shanghai SSH server: Encrypted packet (len=52) 

3 0.363628 shanghai sydney TCP 64839-~22 [ACK] Seq=53 Ack=53 Win=254 Len=0 
图 2 


这 个 现象 就 是 传说 中 的 延迟 确认 ， 我 在 上 一 本 书 中 也 介绍 过 。 为 
了 让 大 家 更 好 地 理解 它 ， 我 们 再 做 个 对 比 实验 : 我 在 笔记 本 上 关闭 了 
延迟 确认 ， 然 后 再 次 连接 悉尼 的 服务 器 。 从 图 3 可 见 2 号 包 和 3 号 包 之 间 
几乎 没有 时 间 差 了 (只 有 0.000121 秒 ， 可 以 忽略 ) 。 


No. Time Source Destination Protocol Info 
1 0.000000 shanghai sydney SSsH Client: Encrypted packet (len=52) 
2 0.148575 Sydney shanghai SSH server: Encrypted packet (len=52) 
3 0.148696 shanghai sydney TCP 1207~22 [ACK] Seq=53 Ack=53 Win=63928 Len=0 
图 3 


启用 延迟 确认 是 有 好 处 的 ， 假 如 在 这 等 竺 的 200 毫 秒 里 ， 上 海 的 笔 
记 本 恰好 有 数据 要 发 ， 就 可 以 在 发 数据 时 朱 带 确认 信息 ， 省 去 了 一 个 
纯粹 的 确认 包 。 图 4 就 符合 这 种 情况 。 笔 记 本 收 到 11 号 包 之 后 ， 等 了 41 
毫秒 左右 〈 即 11 号 包 和 12 号 包 之 间 的 时 间 差 ) 恰好 又 有 一 个 SSH 请 求 要 
发 ， 就 顺便 把 确认 撒 带 过 去 了 ， 因 此 省 掉 了 一 个 纯粹 的 确认 包 。 之 所 


Y ME > mi >» >» 日 DE 
以 有 很 多 TCP 协 议 栈 默认 启用 延迟 确认 ， 正 是 基于 这 个 原 
确认 包 可 以 下 省 市 宽 嘛 。 
0， Time Source Destination Protocol Info 
10 1.498030 shanghai sydney SSH Client: Encrypted packet (len=52) 
11 1.646575 ”Sydney shanghai SSH server: Encrypted packet (len=52) 
12 1.687833 shanghai sydney SSH Client: Encrypted packet (len=52) 
图 4 


延迟 确认 的 坏处 也 很 明显 ， 束 是 会 凭空 多 出 一 段 延迟 。 这 个 机 制 
的 作用 很 像 你 中 午 懒得 去 食 符 吃 版 ， 便 等 到 下 午 出 门 上 课时 顺便 去 吃 
一 点 。 绪 采 可 是 少 跑 了 一 趟 食 特 ， 但 是 吃饭 时 间 却 被 延 后 了 。 

理解 了 延迟 确认 的 原理 ， 我 们 再 回顾 VMware 的 那 篇 文章 。 一 般 来 
说 ， 偶 尔 当 费 200 毫 秒 的 等 待 时 间 并 不 算 严 重 的 问题 ，VMware 为 什么 
要 这 么 在 意 呢 ? 又 不 是 等 竺 很 多 个 200 毫 秒 。 当 我 联想 到 “很 多 个 "时 ， 
终于 明日 了 一 一 这 世界 上 还 真 的 存在 一 种 很 老 的 TCP 的 实现 (RFC 


2582) ， 会 导致 拥塞 时 出 现 多 个 200 毫 秒 的 等 竺 时间。 详情 且 看 下 文 分 
析 。 

图 5 从 客户 端的 视角 演示 了 局 用 延迟 确认 时 ， 某 些 TCP 协 议 栈 在 处 
理 网 络 拥塞 时 的 状况 。 


局 用 延迟 确认 


这 个 传输 过 程 发 生 了 以 下 事件 。 


1. 客户 端 在 同一 时 刻 〈 或 者 说 同一 窗口 ) 发 送 了 9 个 TCP 包 ， 其 中 
3、4、5 号 因为 拥塞 丢失 了 。 

2. 到 达 服 务 器 的 6、7、8、9 号 包 触 发 了 4 个 “Ack 3”， 于 是 客户 端 
快速 重 传 3 号 包 ， 此 时 它 并 不 知道 4 号 包 也 丢 了 。 

3. 由 于 服务 器 上 启用 了 延迟 确认 ， 所 以 它 收 到 3 号 包 之 后 ， 等 待 
了 200 蝇 秒 才 回复 Ack 4 。 

4. 客户 端 重 传 4 号 包 ， 然 后 服务 器 又 等 待 了 200 毫 秒 才 回复 Ack 


5. 客户 端 重 传 5 号 包 ， 然 后 服务 万 又 等 待 了 200 毫 秒 才 回复 Ack 
10。 

6. 客户 端 传输 新 的 10 号 包 ， 目 此 该 网 络 拥 塞 丈 完全 恢复 了 。 

由 于 当时 没有 抓 包 ， 因 此 以 上 分 析 仅 是 我 的 推测 。 还 有 另 一 种 可 
能 是 在 某 个 200 毫 秒 的 延迟 过 程 中 ， 那 些 丢 包 的 RIO (Retransmission 
Timeout) 已 经 被 触发 ， 所 以 进入 了 超时 重 传 阶段 。 无 论 符合 哪 一 种 可 
能 ， 性 能 都 会 严重 下 降 ， 因 此 VMware 建议 关闭 延迟 确认 是 很 有 道理 
的 ， 只 不 过 没 把 原理 说 清楚 。 我 甚至 怀疑 写 这 篇 文章 的 人 也 没 真正 理 
解 ， 因 为 里 面 还 提 到 了 慢 局 动 之 类 不 太 相 天 的 东西 。 

假如 把 延迟 确认 关闭 掉 ， 那 该 TCP 协 议 栈 处 理 拥塞 的 过 程 就 变 成 图 
6 所 示 。 包 还 是 那些 包 ， 不 过 浪费 在 延 述 确认 上 的 600 上 毫秒 束 省 下 来 
了 。 只 要 往返 时 间 不 是 太 长 ， 那 些 丢 包 也 不 会 触发 超时 重 传 ， 所 以 避 
免 了 第 二 种 可 能 。 


我 把 分 析 结 


图 6 


告诉 了 那 位 读者 ， 确 保 这 个 修改 没什么 副作用 。 于 


征 他 壮 着 胆子 关闭 了 延迟 确认 ， 有 果然 VMware 的 性 能 就 毅 升 了 。 图 7 是 
他 在 关闭 之 后 抓 的 网 络 包 ， 和 上 文 分 析 的 一 模 一 样 ， 有 果然 连续 丢 了 很 
多 包 ， 而 且 每 个 重 传 都 需要 确认 一 次 。 


INo. 

147037 
147038 
147039 
147040 
147041 
147042 
147043 
147044 
147045 
147046 
147047 
147048 
147049 
147050 
147051 
147052 


Time 


7.619754000 
7.622595000 
7.622614000 
7.625318000 
7.625325000 
7.628001000 
7.628019000 
7.630617000 
7.630623000 
7.633305000 
7.633322000 
7.635999000 
7.636006000 
7.638615000 
7.638621000 
7.641324000 


Source 

Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
client 
Server 
Client 
Server 
Client 
Server 
Client 


Destination 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 


Protocol Info 

TCP 3260-~50481 [ACK] Seq=153777 Ack=99943465 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] 
TCP 3260~50481 [ACK] Seq=153777 Ack=99944925 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] 
TCP 3260-50481 [ACK] Seq=153777 Ack=99946385 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481~3260 [ACK] 
TCP 3260-~50481 [ACK] seq=153777 Ack=99947845 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99949305 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99950765 Win=1024 Len=0 

TCP [Continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] 
TCP 3260~50481 [ACK] Seq=153777 Ack=99952225 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99953685 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] 


图 7 


Seq=99943465 
Seq=99944925 
Seq=99946385 
Seq=99947845 
Seq=99949305 
Seq=99950765 
Seq=99952225 
Seq=99953685 


我 以 前 分 享 的 案例 都 是 先 在 Wireshark 中 找到 症状 ， 然 后 再 结合 协 
议 分 析 找 到 原因 的 。 而 这 次 纯粹 是 依靠 协议 分 机 ， 预 测 能 从 包 里 看 到 
什么 ， 然 后 再 用 Wireshark 难 证 的 。 听 起 来 似乎 是 完全 靠 灵 感 ， 但 灵感 
不 是 天 生 的 ， 它 来 目 长 期 的 训练 。 只 有 在 Wireshark 中 看 过 了 延迟 确认 
和 大 量 重 传 的 样子 ， 才 可 能 意识 到 它们 放 在 一 起 会 出 大 问题 。 
注意 : 如 果 对 那 篇 VMware 的 文章 感 兴 趣 ， 可 以 在 其 知识 库 http:/kb.vmware.com 中 搜索 
1002598 来 找到 它 。 


前 一 篇 文章 发 布 后 ， 被 一 些 公众 号 转发 了 。 于 是 就 有 资深 技术 人 

员 找 到 我 ， 说 读 完 觉 得 不 过 着 ， 项 望 来 点 有 深度 的 。 好 吧 ， 那 篇 的 确 
只 从 表面 上 介绍 了 延迟 确认 在 网 络 发生 拥 窟 时 的 有 影响， 要 往 深 处 分 析 

的 话 还 是 有 不 少 料 的 。 

完 发 散 一 下 思维 : 除了 VMware 所 建议 的 关闭 延迟 确认 ， 还 有 其 他 
的 方法 可 以 解决 这 个 问题 吗 ? 

答案 是 肯定 的 。 既 然 VMware 的 文章 说 “ 某 些 提供 iSCSI 访问 的 存储 
阵列 在 出 现 网 络 拥塞 时 处 理 不 当 ”， 束 说 明 还 有 些 存 储 阵 列 是 处 理 得 当 
的 ， 即 使 打开 延迟 确认 也 不 怕 。 那 它们 又 是 如 何 处 理 的 呢 ? 我 做 了 很 
多 人 研究 之 后 ， 发 现 它 们 其 实 就 是 启用 了 TCP SACK (Selective 
Acknowledgement) 功能 ， 因 此 在 大 量 丢 包 的 时 候 不 需要 每 个 重 传 包 都 
确认 一 次 ， 也 残 不 人 延迟 确认 的 影响 了 。 图 1 从 客户 端的 角度 演示 了 同 
样 丢 包 的 情况 下 ， 局 用 SACK 的 TCP 协 议 栈 是 怎样 处 理 重 传 的 。 
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客户 端 服务 器 


图 1 

这 个 传输 过 程 发 生 了 以 下 事件 。 

1. 客户 端 在 同一 时 刻 (或 者 说 同一 窗口 ) 发 送 了 9 个 TCP 包 ， 其 中 
3、4、5 号 因为 拥塞 丢失 了 。 

2. 到 达 服 务 器 的 6、7、8、9 号 包 触 发 了 4 个 “Ack 3”。 

3. 由 于 启用 了 SACK， 所 以 服务 器 可 以 在 4 个 “Ack 3” 中 告知 客户 
端 哪些 包 已 经 收 到 了 。 

4. 因为 客户 端 已 经 知道 哪些 包 委 了， 哪些 包 已 经 收 到 ， 所 以 它 可 
以 一 口气 完成 重 传 。 

SACK 信 息 在 Wireshark 中 很 容易 看 到 。 如 图 2 所 示 ， 只 要 把 
“Ack=656925” 和 “SACK: 661857-663035” 这 两 个 因素 结合 起 来 ， 客 户 


端 就 知道 排 在 后 面 的 数据 段 661857-663035 已 经 送 达 ， 但 排 在 前 面 的 
656925-661856 ( 共 4932 字 节 ) 反而 丢失 了 ， 因 此 它 需 要 重 传 这 段 数 
据 。 从 图 3 可 以 看 到 每 个 重 传 包 的 Len 值 ， 四 个 包 加 起 来 恰好 就 等 于 
4932 字 节 。 


No. Time Source Destination Protocol Info 
824 4.472656 Server Client TCP [TCP Dup ACK 821#1] 8888-60479 [ACK] Seq=829 Ack=656925 


咱 


日 SACK: 661857-663035 
Kind: SACK (5) 
Length: 10 
left edge = 661857 (relative) 
right edge = 663035 (relative) 


图 2 
No. Time Source Destination Protocol Info 
825 4.472656 Client server TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=656925 Ack=829 Win=48363 Len=1388 
874 4.531250 Client Server TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=658313 Ack=829 Win=48363 Len=1388 
876 4.535156 Client SerVver TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=659701 Ack=829 Win=48363 Len=1388 
878 4.535156 Client server TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=661089 Ack=829 Win=48363 Len=768 - 
图 3 


由 此 可 见 启用 SACK 其 实 比 关闭 延迟 确认 更 高 效 ， 因 为 它 可 以 一 次 
性 重 传 多 个 丢 包 ， 而 不 用 每 重 传 一 个 就 等 待 一 次 Ack， 白 费 多 个 往返 时 
间 。 这 在 局 域 网 环境 中 的 优势 还 不 太 明 显 ， 如 果 是 在 远程 镜像 中 ， 一 
个 正常 的 往返 时 间 都 要 花 上 百 毫秒 ， 那 就 更 应 该 启用 SACK 了。 我 真 的 
很 好 奇 VMware 为 什么 不 提供 这 个 建议 。 

说 完 SACK， 再 讲 一 个 更 加 有 深度 的 知识 点 : 除了 大 量 重 传 之 外 ， 
延迟 确认 还 会 在 什么 场景 下 严重 影响 性 能 ? 

从 本 质 上 看 ， 延 迟 确认 之 所 以 会 在 大 量 重 传 时 影响 性 能 ， 是 因为 
它 在 该 场景 下 会 多 次 出 现 (其 至 因为 延迟 太 久 而 导致 超时 重 传 ) 。 那 
么 还 有 什么 场景 会 导致 延迟 确认 多 次 出 现 呢 ? 凭空 想象 是 很 难得 到 答 
案 的 ， 不 过 当 你 看 过 的 网 络 包 足够 多 时 ， 肯 定 会 遇 到 一 些 。 我 个 人 遇 
到 最 多 的 是 TCP 窗 口 极 小 的 情况 ， 此 时 启用 延迟 确认 简直 就 是 雪上 加 
霜 。 图 4 演示 了 服务 器 接收 窗口 只 有 2920 字 节 (相当 于 两 个 MSS) ， 且 
关闭 了 延迟 确认 时 的 场景 。 因 为 客户 端 每 发 两 个 包 束 会 耗 光 窗 口 ， 所 
以 不 得 不 停 下 来 等 待 服务 器 的 确认 。 假 如 这 时 候 在 服务 器 上 启用 了 延 


述 确 认 ， 那 29 号 和 30 号 之 间 、32 号 与 33 号 之 间 ...... 以 及 38 号 和 39 号 之 
间 都 需要 多 等 待 200 宫 秒 ， 意 味 着 传输 效率 会 下 降 数 百倍 。 这 个 场景 下 
的 延迟 确认 杀伤 力 巨 大 ， 又 非 党 隐蔽， 所 以 第 一 次 遇 上 的 工程 师 根 本 
不 知 所 措 。 


No. Time Source Destination Protocol Info 
28 1.256466 Client Server TCP [Continuation to #26] 445-2199 [ACK] Seq=2545 Ack=885 Win=65535 Len=1448 - 
29 1.256474 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=3993 Ack=885 Win=65535 Len=1448 - 


30 1.256483 server Client TCP 2199-445 [ACK] Seq=885 Ack=5441 Win=2920 Len=0 TSva1=27476 TSecr=378779 
31 1.256714 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=5441 Ack=885 Win=65535 Len=1448“ 
32 1.256720 client server TCP [Continuation to #26] 445-2199 [ACK] Seq=6889 Ack=885 Win=65535 Len=1448 - 
33 1.256729 server Client TCP 2199-445 [ACK] Seq=885 Ack=8337 Win=2920 Len=0 TSval=27476 TSecr=378779 
34 1.256948 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=8337 Ack=885 Win=65535 Len=1448 
35 1.256953 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=9785 Ack=885 Win=65535 Len=1448 - 
36 1.256961 server Client TCP 2199-445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0 TSval=27476 TSecr=378779 
37 1.257191 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=11233 Ack=885 Win=65535 Len=1448 
38 1.257201 Client server TCP [Continuation to #26] 445-+2199 [ACK] Seq=12681 Ack=885 Win=65535 Len=1448 
39 1.257208 server Client TCP 2199-445 [ACK] Seq=885 Ack=14129 Win=2920 Len=0 TSval=27476 TSecr=378779 


图 4 

其 他 的 场景 我 也 遇 到 过 一 些 ， 不 过 次 数 很 少 ， 吏 不 一 一 列举 了 。 
更 值得 关注 的 ， 是 如 何在 Wireshark 中 发 现 延 迟 确 认 ， 并 计算 它 所 带 来 
的 影响 。 

由 于 延迟 确认 是 一 个 正常 的 TCP 机 制 ， 有 其 积极 的 一 面 ， 所 以 
Wireshark 是 不 会 把 它 当 作 问 题 标 志 出 来 的 ， 而 且 点 击 Analyze Expert 
Info 染 单 也 是 不 会 统计 延迟 确认 的 。 难 道 我们 只 能 靠 人 工 去 计算 每 个 确 
认 包 的 等 待 时间 吗 ? 我 几 年 前 就 因此 吃 过 一 次 亏 一 一 有 位 同事 找 我 分 
析 一 个 性 能 相关 的 网 络 包 ， 我 用 Wireshark 看 了 半天 都 没有 发 现 问题 ， 
所 以 束 斩 安 截 铁 地 说 跟 网 络 无 天 。 后 来 客户 目 己 笑 试 天 闭 了 延迟 确 
认 ， 性 能 居然 束 斋 升 了 ， 导 臻 我 和 同事 都 非常 尴 罚 。 最 后 写 分 析 报 告 
的 时 候 才 想到 办 法 : 只 要 用 “tcp.analysis.ack_rtt>0.2and tcp.len==0” 过 滤 
一 下 ， 隋 可 以 把 所 有 超过 200 毫 秒 的 确认 都 得 出 来 了 (当然 筛 出 来 的 不 
一 定 全 都 是 延迟 和 确认， 追求 精确 的 话 就 逐个 检查 ) 。 图 5 正 是 我 当年 遇 
到 的 那个 网 络 包 ， 只 要 把 过 滤 出 来 的 包 数 乘 以 0.2 秒 ， 就 知道 大 概 浪 费 
了 多 少时 间 。 


Filter: | tcp.analysis.ack_rtt >0.2 and tcp.len==0 [>| Expression... Clear Apply Save 


No. Time Source Destination Protocol Info 本 ， 
6079 121.946662 Server Client TCP 3260-34356 [ACK] Seq=71983377 Ack=191109997 Win=24576 Len=0 
6085 122.346677 server Client TCP 3260-34356 [ACK] Seq=71983425 Ack=191202769 Win=24576 Len=0 
6099 122.746720 Server Client TCP 3260-34356 [ACK] Seq=71983425 Ack=191264617 Win=24576 Len=0 
6221 124.946945 Sserver Client TCP 3260-34356 [ACK] Seq=102185617 Ack=197965957 Win=24576 Len=0 
6226 125.347023 Server Client TCP 3260-34356 [ACK] Seq=102185617 Ack=197994989 Win=24576 Len=0 
6257 125.747026 Server Client TER 3260-34356 [ACK] Seq=102186049 Ack=198074809 Win=24576 Len=0 
6273 126.547094 Sserver Client TEP 3260-34356 [ACK] Seq=102186049 Ack=198144457 Win=24576 Len=0 


图 5 

这 两 篇 文章 所 列举 的 案例 ， 其 实在 现实 环境 中 广泛 存在 。 不 过 由 
于 症状 只 是 性 能 差 ， 所 以 很 多 用 户 以 为 是 带宽 不 足 导 致 的 ， 束 一 直 肪 
着 。 用 Wireshark 抓 个 包 看 看 吧 ， 很 可 能 无 需 升 级 硬件 ， 也 可 以 帮 你 的 
系统 大 幅度 提升 性 能 的 。 


二 次 SPAN 识 


我 原本 以 为 TCP 三 次 握手 不 值得 写 ， 、 某 技术 社区 上 被 提问 
好 几 次 了 。 看 来 感 兴趣 的 人 还 真 不 少 ， 还 是 写 一 篇 吧 。 
a i 过 程 如 图 1 所 示 。 


客户 端 服务 器 


图 1 
从 Wireshark 上 看 到 的 握手 过 程 束 是 图 2 这 样 的 ， 你 可 以 把 Seq 号 和 
Ack 号 代入 图 1 中 ， 看 看 是 否 人 符合 规律 。 


No, Time Source Destination Protocol Info 
1 0.000000 Client server TCP 54395~8888 
2 0.007812 Server Client TCP 8888-54395 
3 0.007812 Client server TCP 54395~8888 


图 2 

当 X 和 Y 的 值 太 大 时 ， 看 起 来 就 不 太 友 好 ， 尤 其 是 需要 对 这 些 号 码 
做 加 减 运 算 时 。 于 是 Wireshatk 提 供 了 一 个 功能 一 一 把 Seq 和 Ack 的 初始 
值 都 置 成 0， 即 用 “相对 值 ”* 来 代替 “真实 值 ”。 我 们 可 以 在 
Edit 一 Preferences 一 ProtocolsTCP 荣 单 中 义 上 Relative Sequence 


SYN| seq=27714969641 Win=65535 Len=0 MSS= 
SYN, ACK] Seq=3290646529 Ack=2771496962 
ACK] Segq=2771496962 Ack=3290646530| Win=1 


Numbers 来 启用 它 。 启 用 之 后 ， 图 2 的 包 就 变 成 图 3 这 样 ， 是 不 是 清 严 了 
很 多 ? 
No. Time Source Destination Protocol Info 

1 0.000000 Client Server TCP 54395—-8888 


2 0.007812 Server Client TCP BB88-54395 
3 0.007812 Client Server TCP 54395--8888 


Win=65535 Len=0 | 
Win=6 
Win=139264 


图 3 

成 功 的 握手 都 是 一 样 的 ， 失 败 的 握手 却 各 有 不 同 ， 因 此 解决 起 来 
还 是 需要 一 些 技巧 的 。 当 我 们 遭遇 TCP 连 接 建立 失败 时 ， 最 稳当 的 排查 
方式 束 是 用 Wireshark 来 分 析 。 网 络 包 不 多 的 时 候 很 容易 入 手 ， 用 肉眼 
观察 束 行 ， 但 如 果 抓 到 的 包 特 别 大 就 需要 过 滤 技 巧 了 。 根 据 我 的 经 
验 ， 握 手 失败 一 般 分 两 种 类 型 ， 要 么 被 拒绝 ， 要 么 是 丢 包 了 “。 因 此 用 
两 道 过 滤 表 达 式 就 可 以 定位 出 大 多 数 失败 的 握手 。 

表达 式 1: (tcp.flags.reset==1) 纺 人 &(tcp.seq==1) 

从 表面 上 看 ， 它 只 是 过 滤 出 Seq 号 为 1， 且 含有 Reset 标 志 的 包 ， 似 
平 与 握手 无 天 。 但 在 启用 Relative Sequence Numbers 的 情况 下 ， 这 往往 
表示 握手 请 求 补 对方 拒 绝 了 ， 结 果 如 图 4 所 示 。 接 下 来 只 需 右 键 选 中 过 
滤 出 的 包 ， 再 点 击 Follow TCP Stream 就 可 以 把 失败 的 全 过 程 显 示 出 
来 ， 见 图 5。 此 次 握手 失败 鸭 原 因 是 服务 右 没 有 在 监听 80 端 口 ， 所 以 拒 
绝 了 客户 端的 握手 请 求 。 


Filter: | (tcp.flags.reset == 1) && (tcp.seq == 1) [= | Expression... Clear Apply Save 
No， Time Source Destination Protocol Info 
26 1.734347 Server Client TCP O073 [nS ACK Sem Se sm 
Mark Packet (toggle) 


lgnore Packet (toggle) 
© Set Time Reference (toggle) 
© Time Shift.., 

Edit Packet 


HW] Packet Comment... 
Manually Resolve Address 


Apply as Filter 
Prepare a Filter 
Conversation Filter 
Colorize Conversation 
SCTP 


Follow TCP Stream 


4 


图 4 


Filter | tcp.stream eq 5 [>| Expression.. Clear Apply Save 

o, Time Source Destination Protocol Info 

25 1.734177 Client SerVver TCP 60173-80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 

26 1.734347 Server Client TCP 80-60173 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 
图 5 


表达 式 2: (tcp.flags.syn==1)&&&(tcp.analysis.retransmission) 

这 道 表达 式 可 以 过 滤 出 重 传 的 握手 请 求 。 一 个 握手 请 求 之 所 以 要 
重 传 ， 往 往 是 因为 对 方 没收 到 ， 或 者 对 方 回 复 的 确认 包 丢 失 了 。 这 个 
重 传 特征 正好 用 来 过 滤 ， 结 果 如 图 6 所 示 。 接 下 来 右键 点 击 过 滤 出 的 
包 ， 再 用 Follow TCP Stream 束 可 以 把 失败 过 程 显示 出 来 ， 见 图 7。 此 次 
握手 失败 的 原因 是 丢 包 ， 所 以 服务 器 收 不 到 握手 请 求 。 


Filter | (tcp.flags.syn == 1) && (tcp.analysis.retransmission) | Expression... Clear Apply Save 
No, Time Source Destination Protocol Info 
847 28.921799 Client server TCP [TCP Retransmission] 38957-5040 [SYN] seq=0 Win= 
1020 34.937546 Client server TCP [TCP Retransmission] 38957-504A—CeYM] < 一 Au 一 
Mark Packet (toggle) 
lgnore Packet (toggle) 
© Set Time Reference (tc 
© TimeShift... 
Edit Packet 


阅 packet Comment.,,. 
Manually Resolve Add 


Apply as Filter 
Prepare a Filter 
Conversation Filter 
Colorize Conversation 


SCTP 
Follow TCP Stream 
图 6 
Filter: | tcp.stream eq 1 [>| Expression... Clear Apply Save 
No, Time Source Destination Protocol Info 
765 25.914925 Client server TCP 38957~5040 [SYN] Seq=0 Win=14480 Len=0 MSS=1460 SACK_I 
847 28.921799 Client server TCP [TCP Retransmission] 38957-5040 [SYN] Seq=0 Win=14480 
1020 34.937546 Client server TCP [TCP Retransmission] 38957-5040 [SYN] seq=0 Win=14480 
图 7 


这 两 个 表达 式 很 好 用 ， 不 过 要 最 快 排 查 出 根本 原因 还 需要 男 一 个 
技巧 ， 即 在 两 端 同时 抓 包 来 分 析 。 为 什么 要 两 并 同 时 抓 呢 ? 请 考虑 图 8 
所 示 的 两 种 状况 。 


TCP 三 次 握手 失败 TCP 三 次 握手 失败 


SN Seq 


客户 端 服务 器 客户 端 服务 器 
图 8 

同样 是 握手 失败 ， 左 图 是 客户 并 发 出 的 包 于 了 ， 右 图 则 是 服务 絮 
回复 的 包 丢 了 “。 不 同 的 丢 包 往往 意味 着 不 同 的 问题 根源 ， 解 决 方式 也 
不 一 样 。 如 有 果 只 在 客户 端 抓 包 ， 那 这 两 种 丢 包 的 症状 看 起 来 就 像 是 一 
样 的 ， 排 查 起 来 也 会 慢 一 些 。 

说 完 握手 失败 的 排查 技巧 ， 我 们 再 来 讲 讲 和 握手 有 关 的 安全 问 
题 。 做 运 维 的 工程 师 们 都 知道 ， 大 规模 DDoS (Distributed Denial of 
Service， 分 布 式 拒绝 服务 攻击 ) 来 临 的 时 候 最 惊 心 动 物 。DDoS 的 形式 
有 很 多 种 ， 其 中 最 流行 的 就 是 基于 三 次 握手 的 SYN flood， 其 原理 是 从 
大 量 主机 发 送 SYN 请 求 给 服务 器 ， 假 装 要 建立 TCP 连 接 。 这 些 SYN 请 求 
可 能 含有 假 的 源 地 址 ， 所 以 服务 器 响应 后 永远 收 不 到 Ack， 就 会 留 下 
half-open 状 态 的 TCP 连 授 。 由 于 每 个 TCP 连 接 都 会 消耗 一 定 的 系统 次 
源 ， 如 采 攻 击 足够 猛烈 ， 此 类 连接 越 建 越 多 ， 服 务 器 的 资源 就 会 被 耗 
光 ， 真 正 的 用 户 访 问 也 会 被 拒绝 。 

Wireshark 可 以 轻易 地 发 现 SYN flood。 有 时 一 打开 包 就 很 显眼 了 ， 
如 图 9 所 示 ， 密 密 麻 麻 都 是 SYN。 假 如 干扰 包 太 多 ， 那 就 点 击 
Analyze 一 Expert Info ~ Chats 来 单 ， 可 以 看 到 SYN 的 总 数量 统计 。 


No. Time 
1 0.000000000 
2 0.000683000 
3 0.001154000 
4 0.001643000 
5 0.002109000 
6 0.002559000 
7 0.003006000 
8 0.003458000 
9 0.003930000 
10 0.004387000 
11 0.004839000 
12 0.005317000 
13 0.005790000 
14 0.006253000 
15 0.006705000 
16 0.007177000 
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Destination Protocol Info 

Victim TCP 53539~80 
Victim TCP 53540~80 
Victim TCP 53541~80 
Victim TCP 53542~80 
Victim TCP 53543~80 
Victim TCP 53544~80 
Victim TCP 53545~80 
Victim TCP 53546-~80 
Victim TCP 53547~80 
Victim TCP 53548~80 
Victim TCP 53549~80 
Victim TCP 53550~80 
Victim TCP 53551~80 
Victim TCP 53552~80 
Victim TCP 53553~80 
Victim TCP 53554~80 


我 们 可 以 把 SYN flood 看 作 TCP 协 议 的 设计 缺陷 ， 


御 ， 却 无 法 根除 。 想 知道 大 公司 都 是 怎样 防御 的 吗 ? 手段 有 很 多 ， 其 
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有 办 法 可 以 防 


中 有 一 些 还 可 以 在 Wireshark 中 看 出 端倪 。 我 假 雄 攻击 了 全 球 最 大 的 假 


药 销售 网 站 ， 
别 了 我 的 不 民意 图， 


然后 把 全 过 程 的 包 抓 下 来 。 从 图 10 可 见 ， 对 方 很 快 就 识 
所 以 Reset (RST) 了 大 多 数 握手 请 求 。 如 果 有 兴 


趣 去 研究 RST 包 里 的 细节 ， 比 如 网 络 层 的 TIL 和 Identification ， 也 许 还 


帝 量 清洗 还 是 TCP 握 手 代 理 之 类 的 。 本 书 不 是 网 络 安全 
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判断 出 究竟 是 ; 

OT 
专 者， 所 以 束 不 展开 分 
Time Source 

Fr .010905000 Hacker 

25 0.011374000 Hacker 

26 0.011828000 Hacker 

27 .012282000 Hacker 

28 .012767000 Hacker 
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图 10 
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被 误解 的 TCP 


人 一 旦 形成 某 种 思维 定 势 ， 就 很 难 再 改变 了 。 知 道 我 收 到 最 多 的 
读者 来 信 是 问 什 么 吗 ? “ 林 工 ， 有 些 TCP 包 发 出 去 之 后 没有 看 到 对 应 的 
Ack， 算 不 算 丢 包 啊 ?” ”这 个 问题 让 我 很 是 好 奇 ， 明 明 RFC 上 没有 这 样 
的 规定 ， 为 什么 总 有 读者 觉得 每 一 个 数据 包 都 应 该 有 对 应 的 Ack 呢 ?后 
来 才 注 意 到 ， 很 多 提问 者 是 做 网 站 开发 出 身 的 ， 已 经 习惯 了 每 个 HTTP 
请 求 发 出 去 ， 就 一 定 会 收 到 一 个 HTTP 响应 〈 见 图 1) ， 因 此 就 把 这 个 
模式 套 到 了 TCP 上 。 其 实 不 止 HTITP， 绝 大 多 数 应 用 层 协 议 都 采用 这 种 
= 问 一 管 的 工作 方式 


Filter: | http [>| Expression.. Clear Apply Save 
No, Time Source Destination Protocol Info 
4 0.006080000 Client Web_server HTTP GET /worigina1/70398db5jwlepzpi0g292j20xc18gdo8. 
243 0.632784000 Web_server Client HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
245 4.956797000 Client Web_server HTTP GET /]arge/70398db5jwlepzpi0g292j20xcl8gdo8. jpg 
687 6.202698000 Web_server Client HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
图 1 


TCP 当 然 也 可 以 采用 这 种 方式 ， 但 并 非 必 要 。 就 像 我 们 不 用 每 天 都 
跟 公 司 算 一 次 工钱 ， 而 是 攒 到 月 底 结 算 一 样 ， 数 据 接收 方 也 可 以 累积 
一 些 包 才 对 发 送 方 Ack 一 次 。 至 于 Ack 的 频率 ， 不 同 的 操作 系统 有 不 同 
的 偏好 ， 比 如 我 实验 室 中 的 Linux 客 户 端 喜欢 每 收 到 两 个 包 Ack 一 次 ， 
见 图 2。 


No. Time Source Destination Protocol Info 
34 15.404708 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=18549 Ack=873 
35 15.404939 server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=19997 Ack=873 
36 15.404948 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=21445 Win=1567 Len=0 TSval= 
37 15.404957 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=21445 Ack=873 
38 15.405187 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=22893 Ack=873 
39 15.405193 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=24341 Win=1748 Len=0 TSval=， 
40 15.405197 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] seq=24341 Ack=873 
41 15.405438 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=25789 Ack=873 
42 15.405445 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=27237 Win=1929 Len=0 TSval=, 
图 2 


而 Windows 客 户 端 则 懒得 多 ， 隔 好 多 个 包 才 Ack 一 次 ， 见 图 3 的 97 
写 个 * 


z 
9 
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ime Source Destination Protocol Info 


86 2.998921 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=49993 Ack=1964 
87 2.998922 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=51421 Ack=1964 
88 2.998924 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=52849 Ack=1964 
89 2.998926 Server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=54277 Ack=1964 
90 2.998927 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] seq=55705 Ack=1964 
91 2.998929 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=57133 Ack=1964 
92 2.998930 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=58561 Ack=1964 
93 2.998932 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=59989 Ack=1964 
94 2.998933 Server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=61417 Ack=1964 
95 2.998943 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=62845 Ack=1964 
96 2.998944 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=64273 Ack=1964 
97 2.998960 Windows_Client server TCP 64944-~445 [ACK] Seq=2027 Ack=65701 Win=256 Len=0 


图 3 

这 两 种 方式 都 是 正常 的 ， 但 Linux 对 流量 更 “大 手 大 脚 ” 一 点 ， 因 为 
纯 Ack 也 算 流 量 的 。 其 实在 网 络 带 视 越 来 越 大 的 今天 ， 人 们 已 经 不 在 乎 
这 种 小 流量 了 。 不 过 手机 操作 系统 还 是 要 慎重 考虑 的 ， 毕 况 蜂 窝 数 据 
是 按 流量 计 费 的 ， 能 省 一 点 是 一 点 。 我 的 安 卓 手机 就 是 每 收 到 一 个 包 
都 会 Ack 的 ， 想 到 这 里 我 的 心 都 在 滴 血 。 图 4 是 我 在 微 博 上 打开 一 张 美 
女 图 时 产生 的 流量 ， 你 看 这 些 密 密 矿 拼 的 纯 Ack， 每 个 都 白费 我 40 字 六 
的 流量 。 


.571283000 Client Web_server 51030~80 Seq=2298005100 Ack=50025943 Win=45440 
.571453000 Client Web_server 51030~80 Seq=2298005100 Ack=50027343 Win=48256 
.571653000 Client Web_server 51030~80 Seq=2298005100 Ack=50028743 Win=51072 
.573684000 Client Web_server 51030~80 Seq=2298005100 Ack=50030143 Win=53888 
.573906000 Client Web_server 51030~80 Seq=2298005100 Ack=50031543 Win=56704 
.574070000 Client Web_server 51030~80 Seq=2298005100 Ack=50032943 Win=59520 


.574228000 Client Web_server 51030~80 Seq=2298005100 Ack=50034343 Win=62208 
.574401000 Client Web_server 51030-.80 Seq=2298005100 Ack=50035743 Win=65024 
.574572000 Client Web_server 51030~80 Seq=2298005100 Ack=50037143 Win=67840 
.574730000 Client Web_server 51030-80 Seq=2298005100 Ack=50038543 Win=70656 
.574885000 Client Web_server 51030~80 Seq=2298005100 Ack=50039943 Win=73472 


图 4 

也 许 以 后 会 有 手机 厂商 优化 它 ， 然 后 以 此 作为 卖点 。 如 果 是 从 我 
这 本 书 里 学 到 的 ， 请 为 它 命 名 “ 林 朗 台 算 法 ”。 

既然 接收 方 不 一 定 收 到 每 个 包 都 要 Ack， 那 发 送 方 怎 么 知道 哪些 包 
虽然 没有 相应 的 Ack， 但 其 实 已 经 送 达 了 呢 ? 记 住 ，Ack 是 有 累积 效应 
的 ， 它 隐 含 了 “在 此 之 前 的 其 他 包 也 已 收 到 ”的 意思 ， 比 如 图 3 中 第 97 号 
包 的 Ack = 65701 不 仅 表 示 收 到 了 96 号 包 (其 
Seq+Len=64273+1428=65701) ， 而 且 上 暗示 之 前 的 其 他 包 也 都 收 到 了 。 


因此 86~95 号 包 虽 然 没 有 被 显 式 Ack， 但 发 送 方 知道 它们 也 已 经 被 送 达 
了 o 

男 一 个 对 TCP 的 广泛 误解 则 和 UDP 相关 。 有 不 少 技 术 人 员 认 为 TCP 
的 效率 低 ， 因 为 其 传输 过 程 中 需要 往返 时 间 来 确认 (Ack) 。 而 UDP 无 
需 确 认 ， 因 此 能 不 停 地 发 包 ， 效 率 就 高 了 。 事 实 真 的 如 此 吗 ? 这 其 实 
是 对 TCP 传 输 机 制 的 严重 误解 。 我 们 可 以 假设 一 个 场景 来 类 比 TCP 的 工 
作 方 式 ， 有 大 批 货物 要 从 A 地 运往 B 地 。 如 果 只 用 一 辆 货车 来 运 的 话 ， 
马路 上 就 只 有 一 辆 车 在 来 回 跑 (回程 相当 于 TCP 的 Ack 包 ) ， 效 率 确实 
很 低 ， 对 TCP 的 误解 可 能 也 出 目 这 个 原因 。 但 如 有 果 在 不 罕 车 的 前 提 下 尽 
量 增加 货车 数量 ， 使 整 条 马路 上 充满 车 ， 总 传输 效率 就 提高 了 。TCP 发 
送 窗 口 的 意义 相当 于 货车 的 数量 ， 只 要 窗口 足够 大 ，TCP 也 可 以 不 受 往 
返 时 间 的 约束 而 源源 不 断 地 传 数据 。 这 束 是 为 什么 无 论 在 局 域 网 还 是 
广域网 ，TCP 还 是 最 受 欢 迎 的 传输 层 协议 。 

当然 TCP 确 实 也 有 因为 往返 时 间 而 降低 效率 的 时 候 ， 比 如 在 传输 小 
块 数据 的 场景 。 本 来 能 在 1 个 往返 时 间 完 成 的 小 事 ， 却 要 额外 耗费 3 次 
握手 和 4 次 挥手 的 开销 ，DNS 查 询 束 符合 这 种 场景 。 目 前 HTTP 基 本 建 
立 在 TCP 连 接 上 ， 所 以 也 会 因为 TCP 的 三 次 握手 而 增加 延迟 。 你 可 能 听 
说 过 Google 发 布 的 QUIC (Quick UDP Internet Connection) 协议 ， 它 就 
是 为 了 消除 TCP 的 延迟 而 设计 的 代替 品 。 在 某 些 领域 可 以 视 为 TCP 的 苋 
争 对 手 ， 目 前 在 Google 的 网 站 上 已 经 可 以 试用 了 。 


这 也 许 称 得 上 最 经 典 的 网 络 问题 ， 很 多 大 师 从 理论 上 分 析 过 的 ， 
我 能 在 现实 中 遇 到 也 算 三 生 有 和 。 


事情 是 这 样 的 。 有 家 公司 来 咨询 一 个 性 能 问题 ， 说 是 从 AIX 备 份 数 
据 到 Windows 极 其 缓慢 ， 只 有 1MB/s， 备 份 所 用 的 协议 是 SFTP。 我 的 第 
一 反应 就 是 抓 个 包 ， 然 后 试 试 Wireshark 的 性 能 三 板 答 。 

1， 从 Statistics Summary 菜 单 可 见 ， 平 均 速度 是 11 Mbit/s， 的 确 只 
比 1MB/s 高 一 些 ， 见 图 1。 


4 Captured 4 Displayed 4 Displayed 3%% 4 Mlarked 4 Mlarked 2% 4 
304 813 89.934% 0 0.000% 
Between first and last packet 0.8l2 sec ~ 0.8]2 sec 
Avg. packets/sec 1112.723 1000.713 


Awg. packet size 1238 bytes 137] bytes 

Bytes 1119304 1114366 99.559% 
Avg. bytes/sec 1377738.740 1371660.611 

Avg, MBit/sec 11.022 10.973 


图 1 
2.， 从 Analyze 一 Expert Infos 荣 单 看 ， 网 络 状况 坟 称 完美 。 请 看 图 
2， 连 一 个 Warnings 和 Notes 都 没有 。 这 样 的 网 络 性 能 怎么 会 差 ? 


Limit to display filter 


3.， 选 定 一 个 从 AIX 发 往 Windows 的 包 ， 然 后 点 击 Statistics 一 TCP 
StreamGraph TCP Sequence Graph (Stevens) 菜单 ， 从 图 3 可 见 ， 这 60 
秒 中 数据 传输 得 很 均匀 ， 没 有 TCP Zero Window 或 者 死机 导致 的 暂停 。 


q 
number[B] Time/Sequence Graph (Stevens) 


60000000 一 


50000000 一 


40000000 一 


30000000 一 


20000000 一 


10000000 一 


图 3 

试 完 三 板 佐 ， 我 们 只 能 得 到 一 个 结论 : 备份 的 确 进行 得 很 慢 ， 但 
是 仅 任 Wireshark 自 带 的 分 析 工 具 找 不 出 根本 原因 ， 这 也 许 意味 着 问题 
不 在 网 络 上 ， 而 是 在 接收 方 或 者 发 送 方 上 。 滁 好 Wireshark 不 但 能 发 现 
网 络 上 的 问题 ， 也 能 反映 出 接收 方 和 发 送 方 的 一 些 配置 ， 只 是 需要 一 
些 技巧 来 发 现 。 

因为 数据 是 从 AIX 备 份 到 Windows 的 ， 所 以 如 果 把 SFTP (SSH File 
Transfer Protocol) 包 过 滤 出 来 ， 理 论 上 应 该 看 到 大 多 数 时 间 花 在 了 从 
AIX 到 Windows 的 传输 上 。 可 是 由 图 4 发 现 ， 从 AIX 到 Windows 的 包 虽 然 


占 多 数 ， 但 没 花 多 少时 间 。 反 而 从 Windows 到 AIX 的 两 个 包 (533 和 
535) 之 间 竟 然 隔 了 0.2 秒 。 该 现象 在 整个 传输 过 程 中 出 现 得 很 频繁 ， 说 
不 定性 能 差 的 原因 就 在 此 处 了 。 只 要 把 根本 原因 找 出 来 ， 就 有 和 希望 解 


决 问题 。 

Fiter ssh 

No. Time 
524 0.411714000 
525 0.411714000 
526 0.411714000 
527 0.411715000 
529 0.411836000 
530 0.411837000 
531 0.411838000 
533 0.412387000 
535 0.606583000 
536 0.606780000 
537 0.606856000 
538 0.606858000 
540 0.606985000 
541 0.606987000 
542 0.606987000 
543 0.606988000 
544 0.606989000 


Source Destination 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
Windows AIX 

Windows AIX 

AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 


| Expression... Clear 
Protocol Info 
ssH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
ssH server: Encrypted packet 
ssH server: Encrypted packet 
SSH Client: Encrypted packet 
SSH Client: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
ssH server: Encrypted packet 
SSH server: Encrypted packet 
SSH server: Encrypted packet 
ssH server: Encrypted packet 
图 4 


Apply Save 


(len=1460) 
(Ten=1460) 
(len=940) 
(Ten=1460) 
(]en=1460) 
(]en=1460) 
(]en=756) 
(len=96) 
(len=656) 
(len=1460) 
(len=1460) 
(len=232) 
(len=1460) 
(len=1460) 
(len=1460) 
(len=1460) 
(len=1460) 


那么 这 0.2 秒 之 间 究 竟 发 生 了 什么 呢 ? 我 把 过 滤 条 件 去 掉 后 得 到 了 
图 5 所 示 的 包 。 可 见 Windows 发 出 533 号 包 之 后 就 停 下 来 等 ， 直 到 0.2 秒 
之 后 AIX 的 Ack (534 号 包 ) 到 达 了 才 发 出 535 号 。Windows 停 下 来 的 原 
因 是 什么 呢 ? 它 在 这 两 个 包 里 总 共 才 发 了 700 多 字 节 (96+656) 的 数 
据 ， 肯 定 不 会 是 因为 TCP 窗 口 受 约 束 所 致 。 


如 果 你 研究 过 TCP 协 议 ， 


Filter: 
No. Time Source 

530 0.411837000 AIX 

531 0.411838000 AIX 

532 0.411851000 Windows 
533 0.412387000 Windows 
534 0.606544000 AIX 

535 0.606583000 Windows 
536 0.606780000 AIX 

537 0.606856000 AIX 


[>| Expression.. Clear Apply Save 


Destination Protocol Info 
Windows ssH server: Encrypted packet (len=1460) 
Windows ssH Server: Encrypted packet (len=756) 
AIX TCP 59140-22 [ACK] Seq=2641 Ack=631713 Win=64240 Len=0 
AIX ssH Client: Encrypted packet (len=96) 
Windows TCP 22-~59140 [ACK] Seq=631713 Ack=2737 Win=65535 Len=0 
AIX SSsH Client: Encrypted packet (len=656) 
Windows SSH server: Encrypted packet (len=1460) 
Windows ssH server : Encrypted packet (len=1460) 
图 5 
会 | 如 7 . 
可 能 已 经 想到 了 目 策 窗口 综合 症 (Silly 


window syndrome) 和 纳 格 (Nagle) 算法 。 在 某 些 情况 下 ， 应 用 层 传递 


给 TCP 层 的 数据 量 很 小 ， 比 如 在 SSH 窜 户 端 以 一 般 速 度 打 字 时 ， 几 乎 是 
逐个 字 世 传递 到 TCP 层 的 。 传 输 这 么 少 的 数据 量 却 要 耗费 20 字 节 卫 头 
+20 字 节 TCP 头 ， 是 非常 当 费 的 ， 这 种 情况 称 为 发 送 方 的 电 笨 窗口 综合 
症 ， 也 叫 “ 小 包 问 题 ”(small packet problem) 。 为 了 提高 传输 效率 ， 纳 
格 提出 了 一 个 算法 ， 用 程序 员 喜 闻 乐 见 的 方式 表达 就 是 这 样 的 : 
it 有 新 数据 要 发 送 
if 数 据 量 超过 MSS ( 即 一 个 TCP 包 所 能 携带 的 最 大 数据 量 ) 
立即 发 送 
else 
if 之 前 发 出 去 的 数据 尚未 确认 
把 新 数据 缓存 起 来 ， 兰 够 MSS 或 等 确认 到 达 再 发 送 
else 
立即 发 送 
end if 
end if 

end if 

图 5 所 示 的 状况 恰好 就 是 小 包 问 题 。Windows 发 了 533 号 包 之 后 ， 本 
应 该 立即 发 送 535 的 ， 但 是 由 于 535 携 带 的 数据 量 小 于 MSS， 是 个 小 
包 ， 根 据 Nagle 算 法 只 好 等 到 533 被 确认 ( 即 收 到 534) 才能 接着 发 。 这 
一 等 就 是 0.2 秒 ， 所 以 性 能 受到 了 大 幅度 影响 。 那 为 什么 AIX 要 等 那么 
入 才 确 认 呢 ? 因为 它 启 用 延迟 确认 了 ， 具 体 可 参考 本 书 的 《一 篇 关于 
VMware 的 文章 》。 

Nagle 和 延迟 确认 本 号 都 没有 问题 ， 但 一 起 用 就 会 影响 性 能 。 解 决 
方法 很 简单 ， 要 么 在 Windows 上 关闭 Nagle 算 法 ， 要 么 在 AIX 上 关闭 延 
迟 确认 。 这 位 客户 最 终 选 择 了 前 者 ， 性 能 立即 提升 了 20 倍 。 

如 有 果 你 足够 细心 ， 也 许 已 经 意识 到 图 3 有 问题 一 -既然 传 输 过 程 中 
会 频繁 地 停顿 0.2 秒 ， 为 什么 图 3 显示 数据 传输 很 均匀 呢 ? 这 是 因为 抓 包 


时 间 太 长 了 ， 有 60 秒 ， 所 以 0.2 秒 的 停顿 在 图 上 看 不 出 来 。 假 如 只 截取 
其 中 的 一 秒 钟 来 分 析 ， 再 点 击 Statistics 一 TCP StreamGraph 一 TCP 
Sequence Graph (Stevens) 菜单 ， 你 就 能 看 到 图 6 的 结果 ，0.2 秒 的 停顿 
束 很 明显 了 。 


Sequence 
number[B] Time/Sequence Graph (Stevens ) 


800000 


700000 


600000 


500000 


400000 


300000 


200000 


100000 


0.05 0.10 015 020 0.25 030 035 0.40 0.45 0.50 0.55 0.60 0.65 0.70 0.75 0.80 


Timels] 


图 6 

按理 说 ， 世 界 上 到 处 都 有 局 用 了 Nagle 和 延迟 确认 的 设备 在 通信 ， 
为 什么 很 少 有 人 说 起 呢 ? 我 猜测 大 多 数 受 害 者 并 没有 发 现 这 个 原因 ，， 
以 为 是 带宽 不 足 所 致 ， 所 以 就 一 直 和 妨 着。 我 要 不 是 用 了 Wireshark， 也 
是 发 现 不 了 的 。 根 据 我 后 来 的 搜索 ， 只 有 斯 坦 福 大 学 的 博士 Stuart 系 统 
地 阅 述 过 一 个 现实 中 的 问题 ,文章 在 他 的 个 人 博客 上 
http://www.stuartcheshire.org/papers/nagledelayedack/。 我 读 完 这 篇 文章 
的 感觉 束 像 遇 到 了 知 首 ， 很 想 把 这 哥们 约 出 来 唱 一 杯 : 


“这 么 隐藏 的 问题 你 是 怎么 发 现 的 ? 太 厉害 了 ! ” 
“和 满 兄 一 样 看 包 啦 ， 分 分 钟 的 事 ! ” 
“ 论 天 下 英雄 ， 唯 司徒 君 与 满 耳 。” 
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一 位 做 销售 的 朋友 最 近 非 常 郁 癌 ， 因 为 即将 到 手 的 单子 被 竞争 对 
手 抢 走 了 。 他 在 饭局 上 诉 杏 的 时 候 ， 技 术 细 下 引起 了 我 的 极 大 兴趣 。 
仔细 询问 之 后 ， 我 把 症状 归纳 如 下 : 他 的 客户 是 一 家 超大 机 构 ， 内 部 
组 织 非 常 庞杂 ， 所 以 从 信息 化 的 角度 看 ， 有 些 用 户 (user) 属于 数 十 个 
用 户 组 (group) 。 当 这 家 机 构 试 用 我 朋友 家 的 NFS 服 务 器 时 ， 发 现 了 
一 个 诡异 的 现象 ， 就 是 有 些 文件 明明 人 允许 某 个 用 户 组 访问 的 ， 但 是 属 
于 该 组 的 用 户 却 访问 不 了 。 为 了 更 清楚 地 分 析 这 个 现象 ， 我 在 实验 室 
搭建 了 一 个 同样 的 环境 来 重 现 问题 。 

1. 在 Linux 客 户 端 创建 了 一 个 测试 账号 叫 linpeiman， 并 将 其 加 入 
到 20 个 用 户 组 中 ， 如 图 1 所 示 。 

剖 linpeiman@shifml:~/grouptest 


[linpeimanlshifmil grouptest]$ groups 

groupl group2 group3 group4 groups groupé group7? group8 group9s 
groupli0 groupili groupil2 groupl3 groupl4 groupls grouple6 group 
17 groupli8 groupl9 group20 国 
[linpeimanlshifmi1 grouptest]$ 

ee EE 


图 1 
2. 把 某 个 NFS 服 务 器 上 的 共享 目 孙 挂 载 到 客户 端 ， 见 图 2 。 


型 root@shifm1/home Ee wD TT we 到 上 Ei 


[root@shifmi ~]# mount 10.32.106.45:/grouptest /home/linpeiman/grouptest * 


[root@shifmi ~]# cd /home/linpeiman/grouptest/ 
[root@shifml grouptest]# 


图 2 

3. 用 root 账 号 在 共享 目录 中 创建 了 20 个 空 的 测试 文件 ， 然 后 
们 逐个 分 配给 第 一 步 提 到 的 那 20 个 用 户 组 ， 并 将 权限 都 设 为 070 ( 表 
用 户 组 拥有 所 有 访问 权限 ) ， 见 图 3。 理 论 上 账号 linpeiman 属 于 这 
用 户 组 ， 所 以 应 该 对 这 20 个 文件 部 有 访问 权限 。 


把 它 


- 


[Li PE ls -lhtr 
total 8.0K 

DeEt .13 21: 
Qct 13 21: 
OctE 13 21: 
Ger ‘13 2Z1s 
Ost 13 21: 
Qe 13 213: 
Oct 13 21: 
Ce 
Oct .13 21: 
det 3 21: 
dct 13 过 二 
Qek 3 I: 
1 加 开 
Oct 13 2 
Oct 13 21: 
EL 1 1 
CE 


root groupl 
root group2 
root group3 
工 口 口 七 group4 
root groups 
TOOt 上 groupse 
root groupT 
root groups 
root groupgd 
root groupli0 
root groupl1 
root groupl2 
root groupl3 
root groupl4 
root groupils 
root groupié 
root groupli7 
root groupli8 Crt 二 过 本 
root 可 FEOUD19 Get 13 21: 
es root group20 5 Oct 13 21: 
Ni[linpeiman@shifml grouptest]$ 


1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 


区 基 忆 与 呈 局 呈 有 


已 品 


上 


4. 用 账号 linpeiman 逐 一 打开 (cat) 这 些 文件 ， 发 现 前 16 个 没有 报 
， 但 是 后 面 4 个 都 遭遇 了 Permission denied 错 误 ， 如 图 4 所 示 。 这 个 症 
关 训 好 像 inpeiman 丰 ` 属 于 后 4 个 用 户 组 似 的 。 


ga 13 


4 1 4 5 16 


ee dt ee for EACH in “seq 1 20*; do cat S$SEACH; done 


cat: 17: Permission denied 
cat: 18: Permission denied 

: 19: Permission denied 
cat: 20: Permission denied 
[linpeiman@shifmi1 grouptest]$ 


图 4 

我 觉得 这 个 实验 结果 完全 不 科学 。 分 明 是 一 模 一 样 的 配置 ， 为 什 
么 就 有 些 文件 不 可 以 访问 呢 ? 重复 了 几 次 实验 都 是 一 样 结果 ， 我 只 好 
笑 试 一 些 其 他 的 方式 来 排查 。 

我 先 在 一 个 本 地 目录 中 创建 了 20 个 文件 ， 并 把 权限 设 成 跟 共 享 
录 上 的 一 样 ， 结 果 发 现 每 一 个 文件 都 可 以 顺利 打开 ， 见 图 5 。 
| 孚 mpemnesimloo 


[linpeiman@shifmi1 local]S 13 -lhtr 


Oct 
Oct 
Oct 
Oct 
Oct 
Oct 
Oct 
Oct 


root groupi 0 
root group2 0 
root group3 0 
root group4 0 
root Group5 0 
root group6 0 
root group7 0 
root group8 0 
root group9 0 Oct 
root Group10 0 Oct 
root Group1l11 0 Oct 
root Group12 0 Oct 
root GFoup13 0 Oct 
root groupi4 0 Oct 
root groupis 0 
root groupi6 0 
root groupi7 0 
root groupi8 0 
root groupi9 0 

1 root group20 0 
[linpeiman@shifmi locall]$ 工 
[linpeiman@shifmi1 locall]$ 


和 
1 
1 
1 
到 
1 
1 
1 
1 
1 
1 
1 
1 
2 
二 
到 
到 
至 
1 


Le ee jj | 
、 下 


-| 


“seq 1 20*; do cat S$EACH; done 


图 5 

愤然 本 地 文件 是 好 的 ， 瓯 说明 问题 很 可 能 出 在 服务 右上 。 而 且 根 
据 那 位 销售 朋友 的 说 法 ， 在 他 们 竞争 对 手 的 NFS 服 务 器 上 确实 不 存在 这 
个 问题 ， 不 知道 是 怎么 做 到 的 。 到 了 这 时 候 肯 定 要 “出 大 招 > 了 ， 我 在 
访问 这 些 文件 时 抓 了 个 网 络 包 下 来 分 析 。 

1. 既然 报错 是 Permission denied ， 我 就 用 了 Ctrl+F 搜 索 字 符 串 
“denied”， 见 图 6。 

二 Wireshark' Find Packet 0 


Find 

By: 人) Display fiter 1) Hex value (@) String 
Filter: | | denied| 

-search In: ] rstring Options— 1rDirection 一 | 


昼 ! Packet list 加 | Case sensitive 
| Packet details | | Character width: 


© Packet bytes Narrow & wide [=| | 


图 6 

2. 这 一 搜 果 然 找到 了 服务 器 响应 的 375 号 包 〈 见 图 7) ， 定 位 到 了 
出 问题 的 时 间 点 。 不 过 真正 有 价值 的 却 是 它 的 上 一 个 包 ， 即 来 自 客 户 
端的 374 号 包 。 从 图 7 底部 可 见 RPC (Remote Procedure Call) 层 只 把 16 
个 Group ID 传 给 服务 絮 ， 而 不 古 20 个 。 


No. _ Time Source Destination Protocol Info 

374 4.005940 Client server NFS V3 ACCESS Call (Reply In 375), FH: Oxc27dde52, [Check: RD MD xT XE] 
375 4.006402 Sserver Client NFs V3 ACCESS Reply (Call In 374), RD MD XT XE] 

4 | WW 


eRenote Procedure calil] Type:call xiID:0x60clc2ca 
田 Fragment header: Last fragment, 172 bytes 
XID: 0x60clc2ca (1623311050) 
Message Type: Call (0) 
RPC Version: 2 
Program: NFS (100003) 
Program Version: 3 
Procedure: ACCESS (4) 
[The reply to this reqguest is in frame 375] 
Credentials 
Flavor: AUTH_UNIX (1) 
Length: 92 
stamp: 0x0038980f 
田 Machine Name: shifml 
UID: 505 
GID: 804 
田 Auxiliary GIDs (16)|[804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819] 


图 7 

3 .这些 及 对 应 着 哪些 用 户 组 呢 ? 我 们 来 看 看 Linux 客 户 端 
的 /etc/group 文 件 ( 见 图 8) ， 果 然 是 前 16 个 ， 后 面 的 4 个 不 知道 为 什么 
被 遗漏 了 。 至 此 真相 大 日 ， 原 来 问题 根源 还 是 在 客户 端的 RPC 层 上 ， 
不 知道 它 为 什么 遗漏 了 后 4 个 用 户 组 ， 服 务 器 是 被 冤 枉 的 。 而 本 地 访问 


加 


之 所 以 没有 出 问题 ， 是 因为 不 需要 调用 RPC 层 发 送 用 户 组 。 


剖 linpeiman®@shiftml:~/grouptest 
i 


groupi:x:804: Winpeiman, root 
:X805: WHnpeiman, root 
XE:806: Winpeiman, root 
:807: Ninpeiman, root 
:808: Winpeiman, root 
:XX:809: inpeiman, root 
:810: Winpeiman, root 
:811: Tinpeiman, root 
XE:812: Winpeiman, root 
:813:Linpeiman,root 
:Dinpeiman,root 
:inpeiman, root 
:inpeiman,root 
:inpeiman,root 
:Dinpeiman,root 
:路 inpeiman, root 
:linpeiman, root 
groupl8:x:821:1l1inpeiman, root 
groupi9:x:822:1inpeiman, root 
group20:X:823:1inpeiman, root 
[linpeimanBshifmil grouptest]$ 


4. 我 查 了 RPC 协 议 所 对 应 的 REFC 5531， 果 然 找 到 如 下 关于 
“gids<16>” 的 定义 。 

structauthsys_parms { 

unsignedint stamp ; 

stringmachinename<255>; 

unsignedintuid; 

unsignedintgid; 

unsignedintgids<16>; 

ee 

看 来 最 多 传 16 个 用 户 组 是 RFC 限 制 的 。 于 是 问题 来 了 ， 那 竞争 对 

手 是 怎样 避免 这 个 限制 的 呢 ? 一 番 调 查 之 后 ， 我 才 发 现 业内 普遍 采用 
了 一 个 顾 为 “机 御 ” 的 办 法 ， 即 把 客户 es 

制 到 服务 器 上 ， 需 要 用 到 用 户 组 的 时 候 承 自己 在 服务 器 上 得 询 ， 
忽略 客户 端 通过 RPC 层 传 过 来 的 信息 。 其 实 这 样 做 会 有 后 遗 症 ， 人 
以 后 在 客户 端 修改 了 用 户 组 ， 但 是 忘记 同步 到 服务 器 上 ， 就 会 出 现 访 
问 问 题 。 

对 我 这 位 做 销售 的 朋友 来 说 ， 虽 然 丢 了 单子 ， 但 是 通过 Wireshark 
发 现 了 根源 ， 能 亡 平 补 牢 也 是 好 的 。 说 不 定 下 一 个 单子 束 能 扳 回 来 
呢 ? 


受 损 的 帧 


有 读者 来 信 问 ,“ 林 工 ， 被 损坏 的 帧 在 Wireshark 中 是 长 什么 样子 
的 ? ”我 一 时 竞 不 知 如 何 回答 ， 因 为 虽然 阅 包 无 数 ， 但 从 来 没有 留意 过 
里 面 有 受 损 的 ， 更 不 知道 它们 长 成 什么 样子 。 后 来 仔细 一 想 ， 才 意识 
到 受 损 的 帧 本 来 就 不 会 显示 在 Wireshark 上 “。 为 什么 呢 ? 这 涉及 数据 链 


路 层 的 错误 检测 机 制 FCS (Frame Check Sequence) : 每 个 帧 在 发 送 前 
都 会 被 发 送 方 校 验 一 次 ， 然 后 生成 4 个 字 和 的 FCS 存 在 帧 尾 。 接 收 方 拿 
到 帧 之 后 ， 又 会 用 相同 的 算法 再 做 一 次 校 难 并 生成 FCS。 假 如 这 次 生成 
的 FCS 和 帧 尾 携 这 的 不 一 致 ， 束 说 明 该 帧 已 被 损坏 ， 应 该 丢 章 了 。 几 1 
表示 了 一 个 以 太 网 帧 的 部 分 组 成 ， 由 于 校 验 是 由 网 卡 完成 的 ， 所 以 在 
主机 上 抓 包 一 般 看 不 到 FCS 区 域 ， 只 能 看 到 灰色 的 4 个 区 域 。 受 损 的 帧 
则 所 有 区 域 都 看 不 到 ， 因 为 整个 被 网 卡 丢 弃 了 。 


EC 
图 1 

既然 如 此 ， 我 们 怎样 才能 判断 有 帧 损坏 呢 ? 有 的 时 候 抓 包 分 析 即 
可 ， 比 如 我 抓 包 发 现实 验 室 里 的 一 台 机 器 会 随机 丢 包 ， 即 便 在 没什么 
流量 的 时 候 都 会 于 。 因 此 我 判断 丢 包 不 是 拥塞 导致 的 ， 而 是 便 件 问题 
导致 了 帧 损坏 ， 后 来 换 了 根 光纤 线 果然 就 好 了 。 如 果 不 想 抓 包 ， 可 以 
在 交换 机 接口 上 检查 FCS 的 错误 统计 ， 比 如 下 面 的 show int 输 出 。Linux 
上 的 netstat-i 命 令 输 出 综合 了 多 种 错误 ， 其 中 也 包括 FCS。 


Errors(Since boot or last clear) : 


FCS Rx : 142 Drops Rx : 0 
Alignment Rx : 0 Collisions Tx : 0 
Runts Rx : 0 Late CollnTx : 0 
Giants Rx : 0 Excessive Colln : 0 
Total Rx Errors : 154 Deferred TIx : 0 


以 上 这 套 理论 我 一 直 深 信 不 疑 ， 没 想到 上 周 侦 然 抓 到 的 一 个 包 却 
差点 颠 禾 信仰 。 请 仔细 看 图 2 中 部 的 大 方 框 ， 我 竟然 在 一 台 普 通 主 机 上 
抓 到 了 一 个 帧 检验 序列 (FCS) 错误 。 既 然 FCS 有 错 ， 表 示 帧 已 经 损坏 
了 ， 为 什么 没 被 网 卡 丢 弃 呢 ?还 有 一 点 很 奇怪 的 ， 束 古 在 那些 没有 损 


坏 的 帧 里 并 没有 看 到 FCS 信 息 (截屏 就 不 贴 出 来 了 ) 。 既 然 要 显示 就 全 
部 显示 ， 为 什么 只 显示 出 错 的 FCS 呢 ? 


No. Time Source Destination Protocol Info 
381 1.680533 Client server UDP source port: 59812 Destination port: 60752 [ 


4 | 


Wh 
由 Frame 381: 74 bytes on wire (592 bits), 174 bytes captured (592 bits 
~ Ethernet II, Src: 2d:74 4b:5c 


0100000042010000 


TraTier: 


日 [Expert Info (Error/Checksum): Bad checksum] 
[Bad checksum] 
[Severity level: Error] 
[Group: Checksum] 
由 Internet Protocol Version 4, src: Dst: 
日 User Datagram Protocol, src Port: 59812 (59812), Dst Port: 60752 (60752) 
source Port: 59812 (59812) 


Destination Port: 60752 (60752) 


图 2 

这 个 现象 已 经 诡异 到 不 能 用 现成 的 理论 来 解释 了 ， 难 道 是 
Wireshark 的 误 报 吗 ? 我 仔细 观察 了 图 2 方 框 内 的 几 个 值 ， 发 现 还 真 的 
是 : 在 UDP 层 看 到 的 长 度 算 上 IP 头 就 是 28+20=48 字 节 ， 再 
人 ° 怎么 可 能 抓 到 74 字 节 呢 ?多 出 来 的 这 12 

节 无 法 解释 来 源 。 我 只 崩 测 这 人 台 主 机 出 了 问题 ， 把 其 他 帧 里 的 12 

节 算 到 这 个 由 里 了 。 因 此 Wireshark 才 会 在 帧 尾 看 到 一 些 多 余 
就 错误 地 当 作 FCS 显 示 出 来 了 。 假 如 这 个 猜测 是 对 的 ， 那 应 该 还 
人 缺失 字 节 的 。 

没 想 到 真 的 有 ， 请 看 图 3 的 351 号 包 。“UDP Length: 40” 表 明 UDP 
0 UDP 头 ) =32 字 市 才 对 ， 但 图 3 底部 的 UDP 层 却 只 携 
带 了 20 字 节 的 数据 ， 说 明 有 12 个 字 世 莫名 其 妙 地 丢失 了 “。 我 没有 证 据 
表明 这 12 个 字 市 一 定 束 是 图 2 多 出 来 的 那些 ， 但 很 可 能 就 是 。 由 于 这 些 

字 节 的 “漂移 *， 导 致 这 两 个 包 也 是 异常 的 ， 所 以 是 个 大 问题 。 后 来 客 
户 更 换 了 IO 模块 ， 问 题 就 消失 了 。 


No. Time Source Destination Protocol Info 


351 1.680030 Client server UDP Source port: 59812 Destination port: 60752 
4 | 


Mh 
[ 田 Erame 351: 62 bytes on wire Ee i 62 bytes captured (496 bits) 
日 Ethernet II, Src: Dst: 4b:5c 
Type: IP (Ox0800) 
由 Internet Protocol Version 4, src: Client 


Dst: Server 


source Port: 59812 (59812) 
Destination Port: 60752 (60752 
日 


由 [Expert Info (Error/Malformed): Bad length value 40 > IP payload length] 
因 Checksum: Ox99d2 [unchecked, not all data available] 
[stream index: 2] 


图 3 

Wireshark 束 是 这 么 神奇 。 虽 然 它 也 有 犯错 的 时 候 ， 但 是 由 于 包 里 
方方面面 的 信息 都 能 呈现 出 来 ， 所 以 我 们 可 以 进行 各 种 推理 ， 从 而 判 
断 出 真正 的 问题 所 在 。 每 一 次 推理 都 是 对 网 络 基础 知识 的 复习 过 程 ， 
非常 有 价值 。 


虚惊 一 场 


上 个 月 收 到 了 一 封 读者 来 信 ， 说 我 上 本 书 中 的 一 个 截图 似乎 有 些 
问题 ， 与 TCP 协 议 不 相符 。 理 论 上 TCP 断 开 连 接 时 的 四 次 挥手 应 该 是 图 
1 这 样 的 (假设 是 服务 器 先 要 求 断 开 ) 。 


TCP 四 次 挥手 


FIN Seq=X, Ack=Y (我 想 断 连接 ) 


服务 占 客户 端 


图 1 
现实 抓 到 的 大 多 数 网 络 包 中 ，X 和 Y 的 值 也 符合 这 个 公式 。 如 图 2 


所 示 ， 你 可 以 把 这 些 数字 套 进 图 1 的 X 和 Y 计 算 一 下 ， 看 看 是 否 符 合 规 
律 。 


o,， Time Source Destination Protocol Info 

28 12.534915 Client server FTP Request: QUIT 

29 12.536071 server Client FTP Response: 221 Goodbye. 

30 12.536073 Sserver Client TCP 21-+53431 [FIN, ACK] Seq=268 Ack=83 Win=139264 Len=0 
31 12.536198 Client server TCP 53431-~21 [ACK] Seq=83 Ack=269 Win=7925 Len=0 


33 12.539666 Server 


Client TCP 21-+53431 [ACK] Seq=269 Ack=84 Win=139264 Len=0 


图 2 

可 是 这 位 读者 发 现 上 本 书 中 却 有 图 3 这 样 的 一 张 图 。 仔 细 看 42 
的 Ack=442， 按 照 上 面 的 理论 它 本 应 该 是 Ack=442+1=443 的 ， 难 道 
户 端 态 记 做 X+1 了 ? 


号 包 
首 是 客 


No, Time Source Destination Protocol Info 
39 10.378327 Client Server FTP Request: QUIT 
40 10.378468 Server Client FTP Response: 221 Goodbye. 
41 10.378474 Server Client TCP 21-36115 [FIN, ACK] Seq=442 Ack=107 Win=139264 Len=! 
42 10.378491 Client Server TCP 36115-~21 [ACK] Seq=107 Ack=442 Win=5856 Len=0 TSval: 


44 10.378867 server Client TCP 21-36115 [ACK] Seq-=443 Ack=108 Win=139264 Len=0 TSsv, 
图 3 

这 封 来 信 让 我 十 分 震惊 ， 因 为 该 图 本 身 演示 的 是 FTP 协 议 ， 没 想到 
这 位 读者 连 传输 层 的 细 市 都 研究 了 ， 如 此 精细 的 读 法 让 我 觉得 写 书 压 
力 好 大 ; 而 且 这 个 发 现 十 分 中 肯 ， 我 也 觉得 是 客户 端 态 记 作 X+1 了 ， 出 
版 之 前 竟然 没 注意 到 这 个 bug 。 

书 中 出 了 差错 还 不 算是 最 糟糕 的 ， 更 大 的 问题 是 在 很 多 机 器 上 抓 
包 都 发 现 了 这 个 现象 。 你 可 不 要 小 瞧 它 ， 四 次 挥手 时 用 错 Ack 值 会 有 什 
么 后 果 呢 ? 它 可 能 导致 TCP 连 接 断 开 失 败 ， 留 下 一 个 本 不 应 该 存在 的 连 
接 ， 久 而 久之 就 会 导致 新 连接 建立 失败 。 那 就 属于 大 bug 了 ， 得 赶紧 上 
报 才 行 。 奇 怪 的 是 我 做 了 几 个 实验 都 发 现 能 成 功 断 开 ， 难 道 是 我 对 协 
议 的 理解 有 偏差 吗 ? 在 接 下 来 的 儿 天 里 ， 我 仔细 地 查阅 了 TCP 的 多 个 
RFC 版 本 ， 比 如 RFC 793、1323、5681 等 ， 企 图 找 出 一 个 相关 的 解释 ， 
但 都 没有 找到 。 

几 天 后 我 跟 Patrick (是 的 ， 就 是 我 上 本 书 中 介绍 的 那 位 奇人 ) 聊天 
时 提 到 了 这 件 事情 ， 老 人 家 很 快 束 回答 ,“ 你 考虑 过 延迟 确认 对 四 次 挥 
手 的 影响 吗 ? 这 个 包 一 点 问题 都 没有 哦 ”延迟 确认 我 当然 知道 了 ， 它 
省 掉 了 四 次 挥手 中 的 第 二 个 包 ， 变 成 下 面 图 4 的 样子 。 


TCP 四 次 挥手 


FIN Seq=X, Ack=Y (我 想 断 连接 ) 


FIN Seq=Y Ack=X+1 (知道 了 ， 
断 开 吧 。 我 也 想 断 连接 ) 


Seq=X+1, Ack=Y+1 (知道 了 ， 断 开 吧 ) 


服务 部 客户 疹 


图 4 
我 在 生产 环境 中 也 抓 到 过 这 个 现象 。 见 图 5 的 33、34、35 号 包 ， 就 
符合 上 述 的 模型 。 可 是 这 跟 图 3 的 现象 还 是 不 一 样 啊 。 


No. Time Source Destination Protocol Info 

31 9.308352 Server Client FTP-DAIFTP Data: 40 bytes 

32 9.308361 Client Server TCP 33001-61657 [ACK] Seq=1 Ack=41 Win=5856 Len=0 TSval=9401060 
33 9.308363 server Client TCP 61657-~33001 [FIN, ACK] Seq=41 Ack=1 Win=65536 Len=0 TSval=4 


35 9.308630 server Client TCP 61657-~33001 [ACK] Seq=42 Ack=2 Win=65536 Len=0 TSval=421211 
* | Wh 


图 5 

Patrickj 进 一 步 点 拨 ， 如 果 拿 掉 图 3 中 的 42 号 包 ， 不 就 跟 图 5 的 延迟 确 
认 场 景 一 模 一 样 吗 ? 也 是 用 三 个 包 完 成 了 挥手 。 那 42 号 包 又 是 各 么 多 
出 来 的 呢 ? 我 很 快 也 想 通 了 : 这 些 包 是 在 服务 器 上 抓 的 ， 网 络 上 又 存 
在 延迟 ， 所 以 跟 客户 端 上 看 到 的 顺序 可 能 不 一 样 。 我 的 眼睛 看 着 服务 
右上 抓 的 包 ， 脑 子 却 从 客户 端的 角度 思考 ， 所 以 才 会 被 混 清 。 那 在 客 
户 端 上 看 到 的 包 应 该 是 怎样 的 呢 ? 发 挥 一 下 想象 力 ， 真 相应 该 如 图 6 所 


示 ， 网 络 延 时 导致 41 号 包 和 42 号 包 在 传输 时 发 生 了 时 间 上 的 “交叉 ”。 
从 客户 端的 角度 看 ，41 号 包 和 42 号 包 的 顺序 应 该 颠倒 一 下 才 对 。 也 就 
是 说 42 号 包 根 本 就 没有 参与 四 次 挥手 过 程 ， 它 只 是 用 来 确认 收 到 40 号 


包 而 已 ,但 由 于 网 络 延 迟 使 它 到 达 服 务 右 时 排 在 了 41 号 包 后 面 ， 所 以 
看 上 去 就 像 挥 手 过 程 的 一 部 分 。 更 巧 的 是 延迟 确认 把 四 次 挥手 减少 成 3 
个 包 ， 所 以 吏 更 有 迷惑 性 了 。 


TCP 四 次 挥手 


Request: QU 


服务 伏 客户 站 


图 6 

多 谢 这 位 眼 尖 的 读者 。 虽 然 没 有 发 现 大 bug， 但 这 个 发 现 对 我 们 做 
网 络 分 析 非 常 有 借鉴 意义 。 在 本 书后 面 的 一 些 文章 中 ， 还 会 讲 到 类 似 
的 情况 。 如 果 你 在 这 里 已 经 觉得 有 点 党 了 ， 建 议 再 细 细 阅读 一 笛 。 作 


为 Wireshark 熟 练 工 ， 必 须 能 从 一 端 抓 到 的 网 络 包 中 推测 出 另 一 端的 概 
况 ， 才 能 分 析出 那些 最 复杂 的 问题 。 


NTLM 协 议 分 析 


有 位 读者 做 项 目 时 过 到 了 麻烦 ， 束 抓 了 个 网 络 包 来 找 我 分 析 。 我 
粗略 一 看 ， 吴 份 验 证 协议 用 的 竟然 是 NTLM， 便 建议 他 改 用 Kerberos。 
没 想到 对 方 说 NTLM 目 前 在 中 国 还 是 用 得 很 多 的 ， 不 想 改 。 我 将 信 将 
疑 ， 咨 询 了 几 位 在 一 线 做 实施 的 工程 师 才 确 认 ， 据 说 连 某 大 银行 内 部 
的 文件 服务 器 都 完全 靠 NTILM 做 身份 验证 。 既 然 如 此 ， 我 束 来 写 一 篇 
NTLM 的 工作 原理 吧 ， 对 中 国 读 者 应 该 会 有 好 处 。 

NTLM 的 全 称 是 NTLAN Manager， 是 Windows NT 时 代 就 出 现 的 身 
份 验证 协议 。 大 多 数 人 都 用 到 过 NTLM， 却 没有 意识 到 它 的 存在 。 我 们 
可 以 做 个 简单 的 实验 来 演示 。 

1， 如 图 1 所 示 ， 我 在 电脑 上 输入 了 一 个 网 络 共享 的 路 径 ， 再 按 一 
下 回 车 。 


= Type the name of a program, folder, document, or Internet 


resource, and Windows will open It for you. 


OQpen: 10.32.106.207\team_shard| ” | 


图 1 
2. 图 2 的 对 话 框 跳出 来 了 ， 要 求 身 份 验 证 ， 即 输入 用 户 名 和 和 密 


码 。 


Enter Network Password 
Enter your password to connect to: 10.32,106.207 


vnx.com\administrator 


Domain: wnx.com 
Remember my credentials 


[x] Logon failure: unknown user name or bad password, 


3. 完成 了 图 2 这 一 步 ， 网 络 共享 就 打开 了 了， 我 们 就 可 以 访问 里 面 
的 文件 。 

在 此 过 程 中 ， 实 际 上 就 用 到 了 NTLM 来 验证 身份 。 我 们 来 看 看 在 
Wireshark 中 是 怎样 体现 的 。 

1. 客户 端 向 服务 器 发 送 了 一 个 NTLM 协 商 请 求 ， 然 后 服务 器 立即 
回复 一 个 随机 字符 串 作 为 Challenge ( 见 图 3) 。 这 个 Challenge 有 什么 用 
呢 ? 我 们 后 面 会 详细 讲 到 。 注 意 服 务 器 的 回复 虽然 是 “Error: 
STATUS_MORE_PROCESSING_REQUIRED”， 看 上 去 好 像 是 出 错 了 
但 实际 上 这 个 所 谓 的 Error 是 正常 流程 的 一 部 分 


Filter ntimssp |] Expression.. Clear Apply Save 
No, Time Source Destination Protocol Info 
216 12.003906 Client Server SMB2 Session Setup Request, NTLMSSP_NEGOTIATE 


217 12.003906 Server Client SMB2 Session Setup Response, Error: STATUS MORE_PROCESSING _ REQUIRED, NTLMSSP_CHALLENGE 
全 上 加 


3 NTLM Secure Service Provider 
NTLMSSP identifier : NTLMSSP 
NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) 
田 Target Name: VNX 


困 Negotiate Flags: Oxe0898211 
NTLM Server Chalienge: 24228c190bcd0356 


图 3 

2. 客户 端 收 到 Challenge 之 后 ， 回 服务 怖 回复 了 图 2 中 输入 的 那个 
用 户 名 VNX\Administrator， 以 及 两 个 Response 值 ( 见 图 4) 。 这 两 个 
Response 是 哪 来 的 呢 ? 它们 都 是 用 hash 过 的 用 户 密 码 对 Challenge 所 进行 
的 加 密 ， 两 种 不 同 的 加 密 方 式 产 生 了 两 个 不 同 的 Response。 加 密 过 程 就 
不 细 说 了 ， 绝 大 多 数 读 者 并 不 需要 知道 (其 实 是 因为 作者 自己 也 了 解 
不 深 ) 。 


Filter: ntimssp [=| Eepression.. Clear Apply Save 
No Time Source Destination Protocol Info 
216 12.003906 Client Server SMB2 session Setup Request, NTLMSSP_NEGOTIATE 
217 12.003906 server Client SMB2 session setup Response, Error: STATUS_MORE_PROCESSING REQUIRED, NTLMSSP_CHALLENGE 
218 12.003906 Client Server SMB2 Session Setup Request, NTLMSSP_AUTH, User: IVNX\Administratol 
mh 


3 NTLM Secure Service Provider 
NTLMSSP identifier: NTLMSSP 
NTLM Message pe: NIMS Sp AUTH a 
1 7790a618ed4607 f5 


3. 服务 絮 收 到 了 之 后 ， 是 不 知道 该 怎样 验证 这 些 Response 的 真 假 
的 。 因 此 它 就 把 Challenge 和 两 个 Response 都 转发 给 域 控 《Domain 


Controller) ， 让 域 控 去 帮忙 验证 真 假 。 在 图 5 中 可 以 看 到 ， 转 发 给 域 控 
的 Challenge 和 Response 和 图 3、 图 4 里 的 是 一 样 的 。 


No, Time Source Destination Protocol Info 
267 12.011718 Server DC RPC_NETLOGON NetrLogonsamLogon request 
268 12.015625 DC server RPC_NETLOGON NetrLogonsamLogon response 


4 | mn 


外 


IDENTITY_INFO: Administrator 
ICchallenge: 54228c190bcd0356 
LM Chal resp 
Length: 176 
size: 176 
日 Bytes Array 
Referent ID: Ox00747055 
Max Count: 176 
offset: 0 
Actual Count: 176 
日 LM Chal resp 
Length: 24 
Size: 24 
日 Bytes Array 
Referent ID: 0x00747055 
Max Count: 24 
offset: 0 
Actual Count: 24 
LM Chal resp: a7790a6l8ed46070ceaf5d7z111459ce6e9b0odxzfb374b041c2| 


图 5 

4. 域 控 收 到 之 后 ， 也 用 hash 过 的 用 户 密码 对 该 Challenge 进 行 加 
密 。 如 果 加 密 结 果 和 这 两 个 Response 一 致 ， 就 说 明 密 人 码 正 确 ， 喘 份 验证 
通过 。 在 响应 时 ， 域 控 还 会 把 该 用 户 所 属 的 群 组 信息 告知 服务 器 ， 见 
图 6 的 部 所 示 。 


回 


No. Time Source Destination Protocol Info 
267 12.0117148 Server DC RPC_NETLOGON NetrLogonsamLogon request 
268 12.015625 Dce Server RPC_NETLOGON NetrLogonsamLogon response 


| Wm 


日 GROUP_MEMBERSHIP_ARRAY 
Referent ID: Ox0002000c 
Max Count: 5 

GROUP_MEMBERSHIP: 
四 GROUP_MEMBERSHIP : 
田 GROUP_MEMBERSHIP : 
GROUP_MEMBERSHIP : 
GROUP_MEMBERSHIP: 


图 6 


5. 于 是 服务 器 就 可 以 告诉 客户 端 ,“ 你 的 身份 验证 通过 了 。” 见 图 
7 的 289 号 包 。 如 果 失 败 的 话 ， 你 看 到 的 吏 不 是 这 么 简单 时 “Session 
Setup Response” 了 ， 而 是 某 个 Error 。 


No Time Source Destination Protocol Info 


216 12.003906 client Server SMB2 Session Setup Request, NTLMSSP_NEGOTIATE 

217 12.003906 Server Client SMB2 session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE 
218 12.003906 Client Server SMB2 Session Setup Request, NTLMSSP_AUTH, User: VNX\Administrator 

289 12.015625 Server Client SMB2 Session Setup Response 


图 7 
这 个 过 程 总 结 下 来 就 如 图 8 所 示 ， 比 起 Kerberos 还 是 比较 简单 的 。 


我 想 用 NTLM 做 身份 验证 


那 你 报 上 名 号 ， 再 把 这 段 字符 串 加 密 给 我 看 。 


我 叫 XXX， 加 密 结果 如 下 : 


大 哥 ， 你 帮 有 我 看 看 这 人 是 不 是 真 的 ? 
真 的 ， 我 还 找到 他 属于 下 列 群 组 : 
你 的 身份 验证 通过 了 


图 8 

明日 了 原理 ， 我 们 惑 可 以 理解 NILM 的 很 多 特征 了 。 

1. 由 于 从 包 里 能 看 到 Challenge 和 Response， 算 法 也 是 固定 的 ， 所 
以 密码 存在 被 破解 的 可 能 。 因 此 微软 并 不 推荐 NTILM， 从 官网 就 可 以 看 
到 “Therefore ，applications are generally advised not to use NTLM ( 因 
此 ， 一 般 不 建议 应 用 程序 使 用 NTLM) ”。 

2. 客户 端 每 访问 一 次 服务 器 ， 就 得 让 域 控 帮忙 验证 一 次 身份 ， 增 
加 了 域 控 的 负担 。 如 果 改 用 Kerberos 束 能 使 用 缓存 的 ticket， 减 少 访问 
域 控 的 次 数 。 

3. 有 些 场合 也 能 体现 出 先进 性 ， 比 如 当 一 个 用 户 不 属于 某 群 组 ， 
所 以 访问 不 了 资源 时 。 解 决 方式 是 在 域 欣 上 为 该 用 户 账号 添加 群 组 ， 


这 时 如 果 用 Kerberos 束 得 重新 登录 来 获得 新 的 群 组 信息 ， 用 NTLM 则 不 
用 o 

当 我 们 遇 到 NTLM 问 题 的 时 候 ， 用 Wireshark 来 排查 是 最 合适 不 过 
的 ， 客 户 端 、 服 务 右 和 域 控 的 问题 都 能 发 现 。 比 如 客户 端 有 时 会 在 图 4 
的 包 中 使 用 一 个 空 的 用 户 名 ， 或 者 其 它 出 人 意料 的 账号 来 验证 身份 ， 
这 种 现象 在 Wireshark 中 一 目 了 然 。 域 控 导 致 的 问题 可 能 我 们 自己 解决 
不 了 ， 需 要 联系 微软 技术 支持 ， 但 是 在 此 之 前 用 Wireshark 定 位 会 快 很 
多 。 比 如 不 久 前 我 过 到 过 一 个 号 份 验证 失败 的 案例 ， 在 Wireshark 中 看 
到 的 域 控 报错 如 图 9 所 示 ， 我 们 据 此 残 能 把 问题 定位 到 域 控 上 。 和 人 微软 的 
工程 师 也 是 根据 这 个 报错 修改 了 Group Policy 来 解决 的 。 这 种 问题 如 果 
没有 用 到 Wireshark， 可 能 连 判 断 是 哪 一 方 导 致 的 都 不 容易 。 


RPC_NETLOGON NetrLogonsamLogon Fegquest 
RPC_NETLOGON NetrLogonsamLogon response, SsTATUS_ACCESS_DENIED 


图 9 


Wireshark 的 提示 


最 近 有 不 少 同 事 开 始 学 习 Wireshark， 他 们 遇 到 的 第 一 个 困难 就 是 
理解 不 了 主 弄 面 上 的 提示 信息 ， 于 是 跑 来 问 我 。 问 的 人 多 了 ， 我 也 总 
结 成 一 篇 文章 ， 硕 望 对 大 家 有 所 帮助 。Wireshark 的 提示 可 是 其 最 有 价 
值 之 处 ， 对 于 初学 者 来 说 ， 如 果 能 理解 这 些 提示 所 隐 舍 的 意义 ， 学 起 
来 定 能 事半功倍 。 

1. [Packet size limited during capture] 

当 你 看 到 这 个 提示 ， 说 明 被 标记 的 那个 包 没 有 抓 全 。 以 图 1 的 4 号 
包 为 例 ， 它 全 长 有 171 字 节 ， 但 只 有 前 96 个 字 节 被 抓 到 了 ， 因 此 
Wireshark 给 了 此 提示 。 


No. Time Source Destination Protocol Info 
1 0.000000 client server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE 
2 0.001482 server Client TCP 443-48113 [SYN, ACK] Seq=0 Ack=l Win=5792 Len=0 MSS=1. 
3 0.001501 Client server TCP 48113-443 [ACK] Seqg=1 Ack=1 Win=5856 Len=0 TSval=4157 
4 0.009432 Client server ssL 
5 0.010923 Sserver Client TCP 443-~48113 [ACK] seq=1 Ack=106 Win=5792 Len=0 TSval=43 


Ud 


= 4: [EL bytes on wire (1368 bits), 96 bytes capturedj (768 bits) 
图 1 

这 种 情况 一 般 是 由 抓 包 方式 引起 的 。 在 有 些 操 作 系 统 中 ，tcpdump 
A 的 前 96 个 字 方 ， 我 们 可 以 用 “-s” 参 数 来 指定 想 要 抓 到 的 
节 数 ， 比 如 下 面 这 条 命令 可 以 抓 到 1000 字 节 。 
[root@my_server/]#tcpdump -i eth0 -s 1000 -w/tmp/tcpdump.cap 


2. [TCP Previous segment not captured | 

在 TCP 传 输 过 程 中 ， 同 一 台 主 机 发 出 的 数据 段 应 该 是 连续 的 ， 即 后 
一 个 包 的 Seq 号 等 于 前 一 个 包 的 SeqtLen (三 次 握手 和 四 次 挥手 是 例 
外 ) 。 如 果 Wireshark 发 现 后 一 个 包 的 Seq 号 大 于 前 一 个 包 的 Seq+Len， 
束 知 道中 间 缺 失 了 一 段 数 据 。 假 如 缺失 的 那 段 数据 在 整个 网 络 包 中 都 
找 不 到 ( 即 排除 了 乱 序 ) ， 就 会 提示 [LTCP Previous segment not 
captured| 。 比 如 在 图 2 这 个 例子 中 ，6 号 


~» 中 人 人 -HF x 3+ 
Seq+Len=1+0=1， 说 明 中 间 有 个 携 市 1448 字 广 的 包 没 被 抓 到 ， 是 
65 = = 39 
Seq=1, Len=1448”。 

No, Time Source Destination Protocol Info 
1 0.000000 Client Server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSVal=: 
2 0.001482 server Client TCP 443-~48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PEI 
3 0.001501 Client server TCP 48113-~443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=41576587 TSecr= 
4 0.009432 Client Server SSL [Packet size limited during capture] 
5 0.010923 server Client TCP 443-48113 [Ack] [5e9=1] Ack=106 win=5792 [Cen=0] Tsval=439748224 Tsel 
6 0.011691 server Client ssL [TCP Previous segment not captured]| Continuation Data[Packet siz! 


LN 
3 Transmission Control Protocol, Src Port: 443 (443), Dst Port: 48113 (48113), |seq: 1449| Ack: 106, 
Source Port: 443 (443) 
Destination Port: 48113 (48113) 


图 2 

网 络 包 没 被 抓 到 还 分 两 种 情况 ， 一 种 是 真 的 于 了 ; 男 一 种 是 实际 
上 没有 丢 ， 但 被 抓 包 工具 漏 掉 了 。 在 Wireshark 中 如 何 区 分 这 两 种 情况 
呢 ? 只 要 看 对 方 回 复 的 确认 (Ack) 就 行 了 。 如 果 该 确认 包含 了 没 抓 到 
的 那个 包 ， 那 束 是 抓 包 工具 漏 挤 而 已 ， 人 否则 束 是 真 的 和 了。 


顺便 分 析 一 下 图 2 这 个 网 络 包 ， 它 是 HTTPS 传 输 异 名 时 在 客户 端 抓 
的 。 因 为 Len: 6672” 的 小 包 〈 即 6 号 包 ) 可 以 送 达 ， 但 “Len: 1448” 的 大 
包 却 于 了 ， 说 明 路 人 径 上 可 能 有 个 网 络 设备 的 MTU 比 较 小 ， 会 丢弃 大 
包 。 后 来 的 解决 方式 证 实 了 这 个 猜测 ， 只 要 把 整个 网 络 路 径 的 MTU 保 
持 一 致 ， 问 题 束 消失 了 。 

3. [TCPACKed unseen segment]| 

当 Wireshark 发 现 被 Ack 的 那个 包 没 被 抓 到 ， 殊 会 提示 [TCP ACKed 
unseen segment]。 这 可 能 是 最 常见 的 Wireshark 提 示 了 ， 下 好 它 几 乎 是 永 
远 可 以 忽略 的 。 以 图 3 为 例 ，32 号 包 的 Seq+Len=6889+1448=8337， 说 明 
服务 器 发 出 的 下 一 个 包 应 该 是 Seq=8337。 而 我 们 看 到 的 却 是 35 号 包 的 
Seq=11233， 这 意味 着 8337 一 11232 这 段 数 据 没有 被 抓 到 。 这 上 段 数据 本 
应 该 出 现在 34 号 之 前 ， 所 以 Wireshark 提 示 了 [TCPACKed unseen 


segment] ° 


No. Time Source Destination Protocol Info 


32 1.256720 Server Client TCP [continuation to #26] 445-2199 [ACK] Ack=885 Win=65535 [Len=1448| Tsval=3787 

33 1.256729 Client Server TCP 2199-445_ [ACK] seq=885 Ack=8337 Win=2920 Len=0 TSval=27476 TSecr=378779 

34 1.256961 Client Server TCP [TCP ACKed unseen segment]|l 2199-~445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0 TSval=27 

35 1.257191 Server Client TCP Continuation to #26] [TCP Previous segment not captured] 445-2199 [ACK] Begq=11233 
图 3 


不 难 想象 ， 在 一 个 网 络 包 的 开头 会 经 常 看 到 这 个 提示 ， 因 为 只 抓 
到 了 后 面 的 Ack 但 没 抓 到 前 面 的 数据 包 。 

4. [TCP Out-of-Order] 

在 TCP 传 输 过 程 中 〈 不 包括 三 次 握手 和 四 次 挥手 ) ， 同 一 台 主 机 发 
出 的 数据 包 应 该 是 连续 的 ， 即 后 一 个 包 的 Seq 号 等 于 前 一 个 包 的 
Seq+Len。 也 可 以 说 ， 后 一 个 包 的 Seq 会 大 于 或 等 于 前 一 个 包 的 Seq。 当 
Wireshark 发 现 后 一 个 包 的 Seq 号 小 于 前 一 个 包 的 Sedq+Len 时 ， 束 会 认为 
是 乱 序 了 ， 因 此 提示 [TCP Out-of-Orderl。 如 图 4 所 示 ，3362 号 包 的 
Seq=2685642 小 于 3360 号 包 的 Seq=2712622， 所 以 就 是 乱 序 。 


No. _ Time Source Destination Protocol Info 
3360 5.007813 Sserver Client TCP 49454-8888 [ACK] ljseq=2712622| Ack=2761 Win=32768 


3362 5.007813 Servtr Client Tep [er Or dr] (054e068 [Ack] EEC 
3363 5.007813 Client server TCP 8888-49454 [ACK|] Seq=2761 Ack=2664291 Win=2457 L 
图 4 

小 跨度 的 乱 序 影响 不 大 ， 比 如 原本 顺序 为 1、2、3、4、5 号 包 被 打 
乱 成 2、1、3、4、5 束 没事 。 但 跨度 大 的 乱 序 却 可 能 触发 快速 重 传 ， 比 
如 打 乱 成 2、3、4、5、1 时 ， 就 会 触发 足够 多 的 Dup ACK， 从 而 导致 1 
号 包 的 重 传 。 

5. [TCP Dup ACK] 

当 乱 序 或 者 丢 包 发 生 时 ， 接 收 方 会 收 到 一 些 Seq 号 比 期 望 值 大 的 
包 。 它 每 收 到 一 个 这 种 包 就 会 Ack 一 次 期 望 的 Seq 值 ， 以 此 方式 来 提醒 
发 送 方 ， 于 是 就 产生 了 一 些 重复 的 Ack。Wireshark 会 在 这 种 重复 的 Ack 
上 标记 [TCP Dup ACK]。 

以 图 5 为 例 ， 服 务 器 收 到 的 7 号 包 为 “Seq=29303，Len=1460”， 所 以 
它 期 望 下 一 个 包 应 该 是 SeqtLen=29303+1460=30763， 没 想到 实际 收 到 
的 却 是 8 号 包 Seq=32223， 说 明 Seq=30763 那 个 包 可 能 丢失 了 。 因 此 服务 
器 立即 在 9 号 包 发 了 Ack=30763， 表 示 “ 我 要 的 是 Sedq=30763”。 由 于 接 下 
来 服务 句 收 到 的 10 号 、12 号 、14 号 也 都 是 大 于 Seq=30763 的 ， 因 此 它 每 
收 到 一 个 就 回复 一 次 Ack=30763， 从 图 中 可 见 Wireshark 在 这 些 回复 上 都 
标记 了 [TCP Dup ACK]。 
7 0.007813 Client server Tcp [Continuation to #3] 55448-445 [ACK] [e029303] Ack-245 win-868 [Cer=1460] 
和 
3 0 00d erper elfene EP [ep Dup ae dil Wand [ocx Sams De td Land sep-dsiad onl 


14 0.007813 Client server TCP [Continuation to #3] 55448-445 [ACK] Seq=46823 Ack=245 Win=868 Len=1460 
15 0.007813 Server Client TCP [TcP Dup ACK 9#3] 445-55448 [ACK] Seq=245 [REKE3075 习 win=16384 Len=0 SLE=32223 SRE=4 


图 5 


6. [TCP Fast Retransmission| 
当 发 送 方 收 到 3 个 或 以 上 [TCP Dup ACK]， 就 意识 到 之 前 发 的 包 可 
能 于 了 ， 于 是 快速 重 传 它 (这 是 RFC 的 规定 ) 。 以 图 6 为 例 ， 客 户 端 收 


到 了 4 个 Ack=991851， 于 是 在 1177 号 包 重 传 了 Seq=991851 。 


No, Time Source Destination Protocol Info 
1169 0.882813 Server Client TCP 49454~8888 [ACK] Seq=1098048 Ack=1105 Win=32768 Len=1448 1T 


1170 0.882813 Server Client TCP 49454-8888 [ACK] Seq=1099496 Ack=1105 Win=32768 Len=1018 1 
1171 0.882813 Client Server TCP 8888-49454 [ACK] seq=1105 Win=2457 Len=0 TSval= 
1172 0.882813 Server Client TCP 49454-8888 [ACK] Seq=1100514 Ack=1105 win=32768 Len=1448 1 
1173 0.882813 Server Client TCP 49454-8888 [ACK] Seq=1101962 Ack=1105 Win=32768 Len=1017 1 


1174 0.882813 Client server TCP [TCP Dup ACK 1171#1]| 8888-49454 [ACK] Seq=1105 lAck=991851 
[TCP Dup ACK 1171#2]| 8888-49454 [ACK] Seq=1105 lAck=991851 
[TCP Dup ACK 1171#3]| 8888-49454 [ACK] Seq=1105 lAck=991851 


1175 0.886719 Client Server TCP 
1176 0.886719 Client Server TCP 

49454-8888 [ACK] [Geo=3051551] Ack= 
图 6 


1177 0.886719 server Client TCP 


7. [TCP Retransmission| 

如 采 一 个 包 真 的 丢 了 ， 义 没有 后 续 包 可 以 在 接收 方 触发 [Dup 
Ack]， 束 不 会 快速 重 传 。 这 种 情况 下 发 送 方 只 好 等 到 超时 了 再 重 传 ， 
此 类 重 传 包 惑 会 被 Wireshark 标 上 [TCP Retransmission]。 以 图 7 为 例 ， 客 
户 端 发 了 原始 包 〈 包 号 1053) 之 后 ， 一 直 等 不 到 相应 的 Ack， 于 是 只 能 
在 100 多 毫秒 之 后 重 传 了 了 〈 包 号 1225) 。 


Filter | tcp.seq == 1012852 加 Expression... Clear Apply Save 


No. Time Source Destination Protocol Info 
1053 0.804688 Client Server TCP 49454-8888 [ACK]1seq=1012852| Ack=1105 Win=32768 Len=| 
1225 0.937500 Client server TCP [TCP Retransmission] 49454~8888 [ACK] ljseq=1012852| Acl 


图 7 

超时 重 传 是 一 个 非常 有 技术 含量 的 知识 点 ， 比 如 等 待 时 间 的 长 短 
就 大 有 学 问 ， 本 文 束 不 细 说 了 ， 和 毕竟 需要 慌 这 个 的 人 很 少 。 

8. [TCP zerowindow] 

TCP 包 中 的 “win=” 代 表 接 收 窗口 的 大 小 ， 即 表示 这 个 包 的 发 送 方 当 
亲人 还 有 多 少 缓存 区 可 以 接收 数据 。 当 Wireshark 在 一 个 包 中 发 现 “win=0” 
上 时， 就 会 给 它 打 上 “TCP zerowindow” 的 标志 ， 表 示 绥 存 区 已 满 ， 不 能 
再 接收 数据 了 。 比 如 图 8 就 是 服务 器 的 缓存 区 已 满 ， 所 以 通知 客户 端 不 
要 再 发 数据 了 。 我 们 甚至 可 以 在 3258~ 一 3263 这 几 个 包 中 看 出 它 的 窗口 
逐渐 减少 的 过 程 ， 即 从 win=15872 减 小 到 win=1472 。 


No. Time Source Destination Protocol Info 


3258 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11928601 Win=15872 Len=0 TSval=226971., 
3259 3.140625 Sserver Client TCP 8888-62758 [ACK] Seq=7467 Ack=11931449 Win=13056 Len=0 TSsva1=226971， 
3260 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11934345 Win=10176 Len=0 TSval=226971, 
3261 3.140625 Sserver Client TCP 8888-62758 [ACK] Seq=7467 Ack=11937241 Win=7232 Len=0 TSval=2269712' 
3262 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11940137 Win=4352 Len=0 TSVval1=2269712， 
3263 3.140625 Server Client TCP 8888-~62758 [ACK] Seq=7467 Ack=11943033 Win=1472 Len=0 TSval=2269712' 
3264 3.140625 server Client TCP [TCP Zerowindow]| 8888-62758 [ACK] Seq=7467 Ack=11944497 Len=0 
3265 3.140625 Sserver Client TCP [TCP Zerowindow]| 8888-62758 [ACK] Seq=7467 Ack=11944529|win=0| Len=0 
3266 3.160156 Server Client TCP [TCP Zerowindow]| 8888-62758 [PSH, ACK] Seq=7467 Ack=11944529 0 

3267 3.167969 server Client TCP TCP Zerowindow]| 8888-~62758 [PSH, ACK] seq=7743 Ack=11944529 [Win=0 


9. [TCP window Full| 

当 Wireshark 在 一 个 包 中 打上 [TCP window Full] 标 志 时 ， 就 表示 这 
个 包 的 发 送 方 已 经 把 对 方 所 声明 的 接收 窗口 耗 尽 了 。 以 图 9 为 例 ， 
Britain 一 直 声 明 它 的 接收 窗口 只 有 65535， 意 味 着 Middle East 最 多 能 给 
人 发 送 65535 字 节 的 数据 而 无 需 确 认 ， 即 “在 途 字 节 数 ”最 多 为 65535 字 
节 。 当 Wireshark 在 包 中 计算 出 Middle East 已 经 有 65535 字 节 未 被 确认 
时 ， 就 会 发 出 此 提示 。 至 于 Wireshark 是 怎么 计算 的 ， 请 参考 本 书 的 
《计算 “在 途 字 和 数 今 一 文 。 


N Time Source Destination Protocol Info 
71 0.392805000 Middle East Britain TCP [TCP Window Fu11] 64560-12345 [ACK] Seq=202344 Ack=1 
72 0.395142000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=142521 Win=65535 Len=0 
73 0.395219000 Middle East Britain TCP [TCP Window Fu11] 64560-12345 [ACK] Seq=205200 Ack=1 
74 0.397470000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=145377 Win=65535 Len=0 
75 0.397549000 Middle East Britain TCP 64560-12345 [ACK] seq=208056 Ack=1 
76 0.400139000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=148233 Win=65535 Len=0 
77 0.400218000 Middle East Britain TCP [TcP window Fu11] 64560-12345 [ACK] Seq=210912 Ack=1 
78 0.402431000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=151089 Win=65535 Len=0 


< | Mh 


田 Checksum: Oxa4dc [validation disabled] 
Urgent pointer: 0 
日 [SEQ/ACK analysis] 
[iRTT: 0.040996000 seconds] 


图 9 

[TCP window Full] 很 容易 跟 |TCP zerowindow| 混淆 ， 实 际 上 它们 
也 有 相似 之 处 。 前 着 表示 这 个 包 的 发 送 方 暂 时 没 办 法 再 发 送 数 据 了 ， 
后 者 表示 这 个 包 的 发 送 方 暂 时 没 办 法 再 接收 数据 了 ， 也 或 是 说 两 者 都 
意味 着 传输 暂停 ， 都 必须 引起 重视 。 

10. [TCP segment of a reassembled PDUI] 

当 你 收 到 这 个 提示 ， 肯 定 已 经 在 Edit~Preferences- 
Protocols-~TCP 荣 单 里 启用 了 Allow sub dissector to reassemble TCP 


streams。 它 表示 Wireshark 可 以 把 属于 同一 个 应 用 层 PDU (比如 SMB 的 
Read Response 和 Write Request 之 类 ) 的 TCP 包 虚拟 地 集中 起 来 。 如 图 10 
所 示 ， 这 一 个 SMB Read Response 由 39 一 48 号 包 共 同 完成 ， 因 此 
Wireshark 在 最 后 一 个 包 中 虚拟 地 把 所 有 包 集 中 起 来 。 这 样 做 有 个 好 
处 ， 就 是 可 以 右键 点 击 图 10 底 部 的 方 框 ， 选 择 Copy = Bytes ~ Printable 
Text Only， 从 而 复制 整个 应 用 层 的 PDU。 做 研发 的 同学 可 能 比较 需要 
文 个 功能 。 


Fimer 加 season car mrv se 
No, Time Source Destnaton 8 et Info Length 
3 5.011522 Client Server REad Andx Request, FiD: Ox004a, 14215 bytes a5 Offseg 0 
393 5,.013998 Server client J [ycr segnent of 3 reassenbled PoU] 

a0 5.014019 Server Cliem Yer [TCP segnent of a reassenbled POU]) 

41 5.014024 Server cc€ilient Tep [YCP segnent of a enim PDOU] 

#2 5,014028 Server ciient Tr [Tver segnent of 3 reassenbled PDU] 

43 5.014033 Server Cilient Tor [TCP segnent of a reassenbled POU] 

44 5.014037 Server 《1fent wr [TYCP segnent of a reassenbled PDU] 

#5 5.034040 Server cilient Tr [Ter segnent of 3 reassenbled roU] 

6 5.014044 Server Cliemt Tr [TCP segnent of a reassenbled PDU] 


47 5.014047 Server Cilient rer [TCP seguent of a reassenbled PDU] 
48 5,014050 Server client Sa Read Andx Mesponse, FID: OxX0043, 21 byres 


» Frame 45: 1313 bytes on wire (10504 bits), 1313 bytes captured (10504 birs) 
5 Erherner I, Src: Clariion 3f:0d:07 (00:60:16:3f:0d:07), Dst: Veware_al:S8:41 (00:50:56:al:58:41) 加 
5 Internet Protocol version #, Srce: Server (10, a Le Es Dst: a IR 32， 106， 0 
» Transmission Control Protocol, Src Port: 445 Ports 
[10 Roassonbled TCP Seqnents 014279 bytes) i 


图 10 

11. [Continuation to #| 

你 看 到 这 个 提示 ， 说 明 已 经 在 Edit- Preferences 一 Protocols 一 TCP 
菜单 里 关闭 了 Allow sub dissector to reassemble TCP streams。 比 如 图 10 
的 那些 包 ， 一 关闭 就 变 成 图 11 这 样 。 


No, Time Source Destination Protocol Info 

38 5.011522 Client Server SMB Read Andx Request, FID: Ox004a, 14215 bytes at offset 0 

39 5.013998 server Client SMB Read AndX Response, FID: Ox004a, 14215 bytes 

40 5.014019 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=3317 Ack=1913 Win=65535 Len=1448 1 
41 5.014024 Server Client TCP [continuation to #39] 445-2212 [ACK] Seq=4765 Ack=1913 Win=65535 Len=1448 1 
42 5.014028 server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=6213 Ack=1913 Win=65535 Len=1448 1 
43 5.014033 server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=7661 Ack=1913 Win=65535 Len=1448 1 
44 5.014037 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=9109 Ack=1913 Win=65535 Len=1448 1 
45 5.014040 server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=10557 Ack=1913 Win=65535 Len=1448 
46 5.014044 Sserver Client TCP [Continuation to #39] 445-2212 [ACK] Seq=12005 Ack=1913 Win=65535 Len=1448 
47 5.014047 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=13453 Ack=1913 Win=65535 Len=1448 
48 5.014050 Server Client TCP [Continuation to #39] 445-2212 [PSH, ACK] Seq=14901 Ack=1913 Win=65535 Len= 


图 11 

仔细 对 比 图 10 和 图 11， 你 会 发 现 Read Response 在 图 10 中 被 算 在 了 
48 号 包头 上 ， 而 在 图 11 中 被 算 到 了 39 号 包头 上 。 这 样 会 带 来 一 个 诡异 
的 结果 : 图 10 的 读 响 应 时 间 为 2.528 毫 秒 (38 号 包 和 48 号 包 的 时 间 
差 ) ， 而 图 11 的 读 响 应 时 间 为 2.476 毫 秒 (38 号 包 和 39 号 包 的 时 间 


差 ) 。 究 竟 哪 个 算 正 确 呢 ? 这 个 问题 很 难 回答 ， 如 果 在 乎 的 是 实际 的 
总 性 能 ， 那 就 看 前 者 ;如 果 想 忽略 TCP/PP 协 议 的 损耗 ， 单 看 服务 器 的 
啊 应 速度 ， 那 融 看 后 者 。 在 某 些 特殊 情况 下 ， 这 两 者 相差 非 常 大， 所 
以 必须 搞 清楚 。 

12. [Time-to-live exceeded(Fragment reassembly time exceeded)| 

ICMP 的 报错 有 好 多 种 ， 大 都 不 难 理解 ， 所 以 我 们 只 举 其 中 的 一 种 
为 例 。[Fragment reassembly time exceeded] 表 示 这 个 包 的 发 送 方 之 前 收 
到 了 一 些 分 片 ， 但 是 由 于 某 些 原因 迟 迟 无 法 组 装 起 来 。 比 如 在 图 12 
中 ， 由 于 上 海 发 往 北京 的 一 些 包 被 分 片 传输 ， 且 有 一 部 分 在 路 上 丢失 
了 ， 所 以 北京 方 无 法 组 装 起 来 ， 便 只 好 用 这 个 ICMP 报 错 告知 上 海 方 。 


Filter | icmp [>| Erpression.. Clear Apply Save 


Noc. Time Source Destination Protocol Info 
404394 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404395 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404396 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404397 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404578 117.994370 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404802 118.762281 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543888 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543889 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543890 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543891 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543892 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543893 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543948 201.440730 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549061 204.896331 Beijing ”shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549062 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549063 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 


图 12 


工 Wireshark 


Wireshark 是 我 工作 中 最 有 价值 的 工具 之 一 。 这 部 分 的 选材 正 来 自 
我 的 工作 经 历 ， 和 者 盖 面 偏 罕 (因为 我 已 经 8 年 多 没有 换 工作 了 ) ,但 是 
比较 深入 ， 因 此 建议 阅读 时 放 慢 速度 。 前 4 篇 的 内 容 有 很 强 的 相关 性 ， 
之 所 以 分 开 来 写 而 不 是 合成 一 篇 ， 是 为 了 给 读者 循序 渐进 的 体验 。 其 
他 每 一 篇 都 比较 独立 ， 所 以 过 到 自己 不 喜欢 的 内 容 可 以 直接 跳 过 ， 这 
不 会 影响 后 面 的 阅读 。 


书 上 错 了 吗 ? 


看 上 去 很 美好 ， 用 了 却 有 上 当 的 感觉 一 一 这 种 心理 落差 不 仅 存在 
于 淘宝 闫 家 和 郁 。 对 Wireshark 初 学 者 来 襄 ， 第 一 次 看 到 网 络 包 的 时 候 也 
会 有 失落 感 ， 甚 至 怀疑 以 前 看 的 书 是 错 的 。 

在 某 些 网 络 书 中 ， 一 个 简单 的 TCP 传 输 过 程 如 图 1 所 示 .4 。 


理想 的 TCP 传 输 


客户 端 服务 需 


图 1 

由 图 1 可 见 ， 客 户 端 每 传 两 个 数据 包 ， 服 务 器 就 立即 Ack 一 下 表示 
已 经 收 到 。 比 如 Ack 3 表示 收 到 了 1 号 和 2 号 两 个 包 ， 正 在 期 待 3 号 包 ，; 
Ack 5 表示 又 收 到 了 3 号 和 4 号 两 个 包 ， 正 在 期 待 5 号 包 。 像 图 1 这 样 美 好 
的 景象 在 数据 接收 方 〈《 即 本 文中 的 服务 器 ) 抓 到 的 包 中 的 确 能 看 到 ， 
比如 图 2 就 很 符合 。23 号 包 的 “Seq=8413，Len=1448”， 两 者 之 和 恰好 等 
于 24 号 包 的 “Ack=9861”， 所 以 24 号 包 就 是 对 23 号 包 (以 及 22 号 包 ) 的 
确认 。 有 兴趣 的 话 可 以 把 图 2 所 有 包 都 对 照 一 下 ， 看 看 是 不 是 非常 吻合 
图 1 的 模型 。 


No, Time Source 
22 15.403709 Client 
23 15.403938 Client 
24 15.403948 Server 
25 15.403958 Client 
26 15.404189 Client 
27 15.404199 Sserver 
28 15.404208 Client 
29 15.404438 Client 
30 15.404444 Server 
31 15.404449 Client 
32 15.404689 Client 
33 15.404697 server 
34 15.404708 Client 
35 15.404939 Client 
36 15.404948 Server 


Destination 
Server 
Server 
Client 
Server 
Server 
Client 
Server 
Server 
Client 
Server 
Server 
Client 
Server 
Server 
Client 


Protocol Info 


TP 
TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TP 
TP 
TCP 
TCP 
TCP 
Te 
TP 


[Continuation to #16] 2049-703 [ACK] Seq=6965 Ack=873 Win=49152 Len=1448 TSVz 
[Continuation to #16] 2049-.703 [ACK] Seq=8413 Ack=873 Win=49152 Len=1448 TSVz 
703-2049 [ACK] seq=873 Ack=9861 Win=843 Len=0 TSsval=2234706033 TSecr=63379094 
[Continuation to #16] 2049-703 [ACK] Seq=9861 Ack=873 Win=49152 Len=1448 TSVz 
[Continuation to #16] 2049-703 [ACK] Seq=11309 Ack=873 Win=49152 Len=1448 TS\ 
703-2049 [ACK] Seq=873 Ack=12757 Win=1024 Len=0 TSval=2234706033 TSecr=63379( 
[Continuation to #16] 2049-703 [ACK] Seq=12757 Ack=873 Win=49152 Len=1448 TS\ 
[Continuation to #16] 2049-703 [ACK] Seq=14205 Ack=873 Win=49152 Len=1448 TS\ 
703-2049 [ACK] Seq=873 Ack=15653 Win=1205 Len=0 TSval=2234706033 TSecr=63379( 
[Continuation to #16] 2049-703 [ACK] Seq=15653 Ack=873 Win=49152 Len=1448 TS\ 
[Continuation to #16] 2049-703 [ACK] Seq=17101 Ack=873 Win=49152 Len=1448 TS\ 
703-~2049 [ACK] seq=873 Ack=18549 Win=1386 Len=0 TSval=2234706033 TSecr=63379( 
[Continuation to #16] 2049-703 [ACK] seq=18549 Ack=873 Win=49152 Len=1448 TS\ 
[Continuation to #16] 2049-703 [ACK] Seq=19997 Ack=873 Win=49152 Len=1448 TS\ 
703-2049 [ACK] Seq=873 Ack=21445 Win=1567 Len=0 TSval=2234706034 TSecr=63379( 


图 2 


然而 这 只 是 从 数据 接收 方 的 角度 所 看 到 的 。 要 知道 网 络 上 存在 延 
迟 ， 所 以 在 数据 发 送 方 ( 即 本 文中 的 客户 端 ) 抓 到 的 网 络 包 就 没 这 么 
理想 了 。 想 象 一 下 ， 同 样 是 图 1 中 的 那些 包 ， 算 上 网 络 延 迟 的 传输 过 程 
会 是 什么 样子 的 ? 请 看 图 3， 这 些 Ack 包 到 达 客户 端 时 会 滞后 一 些 ， 所 
以 客户 端 发 完 6 号 包 才 收 到 Ack 3， 发 完 8 号 包 才 收 到 Ack 5。 虽 然 看 上 去 
有 点 “ 答 非 所 问 ”， 但 这 是 完全 符合 TCP 协 议 的 。 因 此 建议 初学 者 最 好 两 
边 同 时 抓 包 ， 对 照 着 看 ， 以 免 产 生 误 解 。 


真实 有 反映 两 端的 TCP 传 输 


客户 端 服务 器 


图 3 

按理 说 图 3 这 种 交叉 斜 线 的 表示 方法 是 最 精确 的 ， 我 在 书 中 为 什么 
很 少 采用 呢 ? 因为 本 书 介 绍 的 是 Wireshark， 而 用 Wireshark 打 开 一 个 包 
只 能 看 到 一 边 的 情况 ， 所 以 我 宁愿 只 站 在 其 中 一 边 的 角度 来 画图 ， 这 
样 会 更 接近 在 Wireshark 中 看 到 的 样子 。 当 然 选 择 哪 一 边 也 很 有 讲究 ， 
假如 从 一 开始 就 站 在 数据 发 送 方 ( 即 本 文中 的 客户 端 ) 的 角度 看 ， 读 
者 一 定 会 觉得 有 点 乱 ， 模 型 图 请 看 图 4。 


实际 在 客户 问 看 到 的 TCP 传 输 


客户 端 服务 需 


图 4 

从 Wireshark 上 看 真实 的 包 就 更 和 恩 了 ， 图 5 就 是 一 个 在 数据 发 送 方 上 
抓 到 的 包 。 其 中 7 号 包 是 “Seq=263611，Len=249”， 两 者 之 和 263860 远 
远大 于 8 号 包 的 “Ack=3284”， 可 见 Ack 包 严重 清 后 了 。 我 在 上 一 本 书 中 
尽量 避免 引入 这 样 的 截图 ， 就 是 担心 读者 被 这 迟 来 的 Ack 混 消 了 “。 然 而 
丑 媚 妇 是 早晚 要 见 公 姿 的 ， 当 我 们 的 研究 深入 到 一 定 程度 ， 两 边 抓 到 
的 网 络 包 都 必须 学 会 面 对 。 有 的 时 候 甚 至 只 能 分 析 看 上 去 混乱 的 那 一 
边 ， 接 下 来 的 两 篇 文章 就 是 这 样 。 


No, Time 
6 0.000000 
7 0.000000 
8 0.339843 
9 0.339843 
10 0.339843 
11 0.457031 
12 0.457031 
13 0.457031 
14 0.589843 
15 0.589843 
16 0.589843 
17 0.589843 
18 0.589843 
19 0.589843 
20 0.628906 


Source 

Client 
Client 
server 
Client 
Client 
server 
Client 
Client 
Server 
Client 
Client 
Server 
Client 
Client 
server 


Destination Protocol Info 


Server 
server 
Client 
SerVver 
Server 
Client 
server 
Server 
Client 
Server 
Server 
Client 
Server 
Server 
Client 


TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TCP 
TP 
TCP 
TCP 
TCP 
TCP 
EP 


65096-~8888 
65096-~8888 
8888-65096 
65096-~8888 
65096-~8888 
8888-65096 
65096~8888 
65096-~8888 
8888--65096 
65096~8888 
65096-~8888 
8888-65096 
65096-~8888 
65096-8888 
8888--65096 


[ACK] 
[AcK] 
[AcKk] 
[AcK] 
[ACK] 
[ACK] 
[Ack] 
[AcK] 
[AcK] 
[AcK] 
[ACK] 
[AcKk] 
[AcK] 
[AcK] 
[AcK] 


图 5 


Seq=262223 Ack=1l1 Win=65535 Len=1388 TSval=21; 
Seq=263611 Ack=1l1 Win=65535 Len=249 Tsval=212 
Seq=1 Ack=3284 Win=4096 Len=0 TSval=2955010 - 
Seq=263860 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=265248 Ack=1 Win=65535 Len=180 TSsval=212 
seq=1 Ack=5033 Win=4096 Len=0 TSval=2955010 - 
Seq=265428 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=266816 Ack=l Win=65535 Len=361 TSval1=2121 
seq=1 Ack=6876 Win=4096 Len=0 TSval=2955010 - 
Seq=267177 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=268565 Ack=1 Win=65535 Len=455 TSsval=212 
seq=1 Ack=8529 Win=4096 Len=0 TSval=2955010 - 
Seq=269020 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=270408 Ack=l Win=65535 Len=265 TSval=2121 
seq=1 Ack=10372 Win=4096 Len=0 TSval=2955010 


假如 本 文 的 内 容 让 你 觉得 有 点 犯 迷糊 ， 可 能 需要 停 下 来 慢 慢 消 
化 ， 甚 至 多 读 两 遍 。 理 解 了 这 个 ， 才 能 翻 到 下 一 篇 ， 看 看 如 何 计算 "在 
途 字 节 数 ”。 


我 一 直 齐 记 斯 蒂 分 - 
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的 金玉 民 言 一 一 每 写 一 道 数学 公式 束 会 失 


去 一 半 读 者 。 不 过 为 了 深度 分 析 网 络 包 ， 有 时 候 是 不 得 不 计算 的 ， 好 
在 小 学 一 年 级 的 加 减法 束 够 用 了 。 

网 络 的 承载 量 就 是 一 个 需要 计算 的 值 。 怎 样 理解 这 个 概念 呢 ? 如 
图 1 所 示 ， 一 架 波 音 747 能 够 承载 上 万 个 小 包 囊 ， 而 一 架 无 人 机 只 能 承 
载 一 个 ， 这 就 反映 了 它们 不 同 的 承载 量 。 换 个 角度 ， 也 可 以 说 承载 量 
忠 古 处 于 运输 工具 中 的 货物 量 ， 即 已 经 从 源 仓库 发 货 ， 但 还 没有 a 到达 
目的 地 的 包 右 数量 。 


图 1 

和 运输 机 类 似 ， 网 络 承载 量 也 可 以 用 已 经 发 送出 去 ,但 尚未 被 确 
认 的 字 市 数 来 表示 。 在 英文 技术 文档 中 ， 形 象 地 用 “bytes in flight" 来 描 
述 它 ， 我 觉得 用 “在 途 字 市 数 ” 来 翻译 最 好 。 

飞机 如 果 超 载 了 ， 是 会 发 生 严 重 事故 的 。 而 在 途 字 市 数 如 果 超 过 
网 络 的 承载 能 力 ， 也 会 丢 包 重 传 ， 这 就 是 我 们 需要 计算 它 的 原因 。 怎 
么 计算 呢 ? 假 如 网 络 上 只 有 一 个 TCP 连 接 在 通信 ， 那 么 还 可 以 通过 带宽 


和 延迟 来 计算 最 多 能 承载 多 少 在 途 字 市 数 。 而 实际 环境 往往 如 图 2 所 
示 ， 同 一 条 网 络 路 径 是 由 多 台 主 机 之 间 共 享 的 ， 根 本 不 知道 多 少 比例 
的 带宽 是 分 配给 某 个 TCP 连 接 。 这 时 候 就 需要 用 到 网 络 神器 Wireshark 
来 分 机 了 。 


枉 二 一 一 网 络 路 径 


/ S 
区 ”了 


图 2 

分 析 之 前 要 驳 抓 包 。 应 该 在 哪 一 端 抓 呢 ? 我 们 先 两 边 都 尝试 一 
下 。 上 文 《 书 上 错 了 吗 ? 》 已 经 交代 过 ， 网 络 延 迟 会 导致 同样 的 网 络 
包 在 两 端 体现 出 不 同 的 顺序 ， 并 用 下 面 的 图 3 演示 。 


真实 反映 两 端的 TCP 传 输 
3 


A 


客 尸 端 服务 此 


图 3 

我 在 图 3 的 服务 器 上 随机 挑选 一 个 时 间 点 并 标志 为 T1。 由 于 服务 器 
在 该 点 之 前 收 到 8 号 包 并 立即 回复 了 “Ack 9”( 表 示 9 号 之 前 的 包 都 收 到 
了 ) ， 所 以 在 途 字 节 数 为 0。 也 就 是 说 ， 在 数据 接收 方 抓 的 包 里 是 看 不 
到 在 途 字 节 数 的 ， 没 有 分 析 意 义 。 

接着 我 在 图 3 的 客户 端 随机 挑选 一 个 时 间 点 并 标志 为 T2， 由 于 在 该 
时 间 点 之 前 10 号 包 已 经 发 出 去 ， 但 收 到 的 “Ack 7” 只 表示 7 号 之 前 的 包 都 
收 到 了 ， 也 即 意味 着 7、8、9、10 号 包 都 还 没有 确认 ， 所 以 在 途 字 节 数 
就 是 这 4 个 包 所 携带 的 数据 量 。 这 说 明 在 数据 发 送 方 抓 到 的 包 才 能 用 来 
分 析 在 途 字 节 数 。 


从 模型 图 中 理解 了 原理 ， 接 下 来 就 可 以 用 Wireshark 来 分 析 真 实 的 
包 了 。 图 4 是 在 客户 端 (数据 发 送 方 ) 抓 到 的 ， 如 果 我 们 想 知道 第 
0.400000 秒 时 的 在 途 字 太 数 ， 应 该 如 何 计算 呢 ? 


N 


Time Source Destination Protocol Info 

6 0.000000 Client server TCP 65096~8888 [ACK] Seq=262223 Ack=1l1 Win=65535 Len=1388 TSval=2] 
7 0.000000 Client server TCP 65096-8888 [ACK] Seq=263611 Ack=l Win=65535 Len=249 TSsval=21: 
8 0.339843 Server Client Tcp 8888-65096 [ACK] Seq=1 Win=4096 Len=0 Tsval=2955010 


9 0.339843 Client server TCP 65096-8888 [ACK] seq=263860 Ack=l Win=65535 Len=1388 TSval=2] 
10 0.339843 Client Server TCP 65096-8888 [ACK] Ehck- win=65535 [Cen=130] Tsval=21: 
11 0.457031 server Client TCP 8888-65096 [ACK] Seq=1 Ack=5033 Win=4096 Len=0 TSval=2955010 
12 0.457031 Client server TCP 65096-~8888 [ACK] Seq=265428 Ack=1 Win=65535 Len=1388 TSval=2] 


13 0.457031 Client server TCP 65096-~8888 [ACK] Seq=266816 Ack=1 Win=65535 Len=361 TSVval=21: 
14 0.589843 server Client TCP 8888-65096 [ACK] Seq=1 Ack=6876 Win=4096 Len=0 TSval=2955010 


图 4 

在 该 时 间 点 之 前 客户 端 发 送 的 是 10 号 包 ， 即 “Seq=265248 ， 
Len=180” 字 节 ， 表 示 序 号 在 265248+180=265428 之 前 的 字 节 已 经 发 送出 
去 了 。 而 第 0.400000 秒 之 前 服务 器 的 Ack 为 3284， 表 示 序 号 在 3284 之 前 
的 字 节 已 经 收 到 了 。 那 么 在 途 字 市 数 就 是 265428-3284=262144 字 敢 。 
如 果 要 归纳 出 一 条 公式 ， 可 以 表示 成 : 

在 途 字 下 数 =Seq+Len-Ack 

其 中 Seq 和 Len 是 来 自 上 一 个 数据 发 送 方 的 包 ， 而 Ack 则 来 自 上 一 个 
数据 接收 方 的 包 。 我 们 再 拿 第 0.500000 秒 来 练习 一 下 ， 套 用 公式 可 以 算 
出 在 途 字 节 数 应 该 是 266816+361-5033=262144， 与 第 0.400000 秒 的 一 
样 多 。 

理解 了 在 途 字 节 数 的 计算 方式 ， 就 可 以 翻 到 下 一 篇 《估算 网 络 拥 
塞 点 》 了 “。 要 是 还 不 太 理解 ， 建 议 多 读 两 遍 。 


9 


估算 网 络 拥塞 点 


前 两 篇 写 了 那么 多 ， 其 实 痢 是 为 了 给 本 文 的 话题 作 铺 的 。 这 个 话 
题 就 是 网 络 拥塞 点 一 一 当 发 送 方 一 口气 向 网 络 中 注入 大 量 数据 时 ， 就 
可 能 超过 该 网 络 的 承受 能 力 而 导致 拥塞 ， 这 个 足以 触发 拥塞 的 数据 量 


就 称 为 拥塞 点 。 从 定义 上 看 ， 拥 赛 点 和 上 文 所 介绍 的 “在 途 字 节 数 ” 
是 不 是 有 关系 呢 ? 

确实 有 关系 。 假 如 把 网 络 路 径 想象 成 一 条 河流 ， 发 送 方 是 水 源 ， 
接收 方 是 入 海口 ， 那 在 途 字 节 数 怠 是 河 里 的 水 量 。 当 水 源 的 流速 超过 
了 入 海口 的 流速 ， 河 里 的 水 量 束 会 越 来 越 多 ， 直 至 洲 出 。 所 以 大 致 可 
以 认为 ， 发 生 拥 罕 时 的 在 途 字 节 数 即 是 该 时 刻 的 网 络 拥塞 点 。 明 白 了 
这 一 点 ， 估 算 拥 塞 点 束 可 以 简化 成 找 出 拥塞 时 刻 的 在 途 字 下 数 了 。 

那 又 如 何在 Wireshark 中 找到 拥塞 时 刻 呢 ? 众所周知 ， 拥 塞 的 特征 
是 连 串 丢 包 ， 丢 包 之 后 就 会 重 传 ， 而 Wireshark 是 能 够 标识 出 重 传 包 
的 。 因 此 我 们 可 以 根据 这 个 规律 来 寻找 先 从 Wireshark 中 找到 一 连 串 
重 传 包 中 的 第 一 个 ， 再 根据 该 重 传 包 的 Seq 值 找到 其 原始 包 ， 最 后 计算 
该 原始 包 发 送 时 刻 的 在 途 字 节 数 。 由 于 网 络 拥 窟 束 是 在 该 原始 包 发 出 
去 的 时 刻 发 生 的 ， 所 以 这 个 在 途 字 和 数 就 大 致 代 表 了 拥塞 点 的 大 小 。 

具体 操作 步骤 如 下 。 

1. 在 Wireshark 上 单 击 Analyze 沫 单 ， 再 单 击 Expert Info 选 项 ， 得 到 
图 1 的 重 传统 计 表 。 
| 加 werorc 7007 poor iio OO < 


Errors: 3 (2390) | Warnings: 3 (159) | Notes: 121 (4538) |Chats: 0 (0) | Details 7087 | Packet Comments 0 | 
Group 4 Protocol 4 Summary 


日 Sequence TCP Retransmission (suspected) 
Packet: 
Packet: 
Packet: 
Packet: 
Packet: 


Help 


图 1 
2. 点 击 第 一 个 重 传 包 No.1225， 可 见 它 的 Seq=1012852。 于 是 用 
“tcp.seq==1012852” 作 为 过 滤 条 件 ， 见 图 2。 


Fikter: tcp.seq == 1012852 -| Expression,... Clear Apply Save 


No. Time Source Destination Protocol Info 

1225 0.937500 Client server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1012852 Ack=1105 
1226 0.937500 Server Client TCP [TCP Dup ACK 1171#51] ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=991851 
1227 0.937500 Client Server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1026650 Ack=1105 
1228 0.937500 Server Client TCP [TCP Dup ACK 1171#52] ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=991851 
1229 0.937500 Client Server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] Seq=1033235 Ack=1105 
1230 0.941406 server Client TCP [TCP Dup ACK 1171#53] ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=991851 
< 


中- 


日 Transmission Control Protoco1，Src Port: 49454 C49454), Dst Port: i -tcp-1 C8888), a 1012852， i 1105, 
Source port: 49454 (49454) 
Destination port: ddi-tcp-1 (8888) 
[stream index: 0] 
sequence number: 1012852 (relative sequence number) 
[Next sequence number: 1013668 (relative sequence number)] 
Acknowledgment number: 1105 (relative ack number) 


图 2 
点 击 Apply 过 小 之 后 得 到 了 原始 包 No.1053， 见 图 3。 


Filter: | tcp.seq == 1012852 [= | Eepression.. Clear Apply Save 

No, Time Source Destination Protocol Info 

1053 0.804688 Client server TCP 49454 > ddi-tcp-1 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=816 TS 
1225 0.937500 Client server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1012852 Ack=1105 


* 咱 


唱 TEST el Os src Port: 49454 (49454), Dst Port: re -tcp-1 C8888). seq: 1012852, A 1105. 
Source port: 49454 (49454) 
Destination port: ddi-tcp-1 (8888) 
[stream index: 0] 
sequence number: 1012852 (relative sequence number) 
[Next sequence number: 1013668 (relative sequence number)] 
Acknowledgment number: 1105 (relative ack number) 


图 3 
4， 选 定 1053 号 包 ， 然 后 点 击 Clear 清 除 过 滤 。 可 见 上 一 个 来 自 服务 
器 端的 包 是 1051 号 包 ， 见 图 4。 


Fitter [= | xpression.. Clear Apply Save 


No. Time Source Destination Protocol Info 

1051 0.804688 Server Client TCP ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=910546 Win=2457 Len=0 TSval=24415168 TSecr= 
1052 0.804688 Client Server TCP 49454 > ddi-tcp-1 [ACK] Seq=1011404 Ack=1105 Win=32768 Len=1448 TSval=41365538 TT! 
1053 0.804688 Client Server TCP 49454 > ddi-tcp-1 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=816 TSval=41365538 TS! 


« LL 


图 4 
. 利用 上 文 《计算 “ 在 途 字 节 数 ”》 的 公式 ， 可 知 当 时 的 在 途 字 
数 四 1012852 〈No.1053 的 Sedq ) +816 ( No.1053 的 Len) -910546 
(No.1051 的 Ack) =103122 字 节 。 
就 这 样 ， 该 时 刻 的 拥塞 点 被 估算 出 来 了 。 这 个 方法 不 一 定 很 精 
确 ， 但 是 绝对 有 参考 意义 。 我 们 最 好 多 次 采样 ， 然 后 选 定 一 个 合适 的 
值 作为 该 连接 的 拥塞 点 。 什 么 样 的 值 才 算 合适 ? 我 个 人 认为 不 应 该 取 


平均 值 ， 而 应 该 取 一 个 偏 小 的 。 比 如 说 10 次 采样 中 有 5 次 是 32KB，5 次 
是 40KB， 那 宁愿 把 拥塞 点 定 为 32KB， 而 不 是 平均 值 36KB 。 

为 什么 要 如 此 保守 呢 ? 这 得 从 估算 拥塞 点 的 目的 开始 说 起 。 我 们 
辛 辛 昔 苦 地 估算 它 ， 是 为 了 能 把 发 送 窗 口 限 制 在 这 个 拥塞 点 以 下 ， 从 
而 避免 拥塞 ， 提 高 传输 性 能 。 限 制 在 32KB 以 下 时 可 以 完全 消除 拥塞 ， 
而 假如 取 了 个 平均 值 36KB， 那 就 只 能 减少 二 分 之 一 的 拥塞 。 我 在 上 一 
本 书 中 已 经 详细 分 析 过 ， 每 一 次 拥塞 带 来 的 性 能 影响 都 很 大 ， 即 使 千 
分 之 一 的 概率 都 足以 导致 性 能 大 滑坡 ， 保 守 一 点 还 是 值得 的 。 至 于 估 
算 结束 后 ， 如 何在 系统 中 把 窗口 限制 在 拥塞 点 以 下 ， 不 同 的 操作 系统 
有 不 同 的 方法 ，Windows 环 境 可 以 参考 KB 224829 的 步骤 。 


SO 


当 你 开始 动手 估算 网 络 的 拥塞 点 ， 很 可 能 会 遇 到 一 个 诡异 的 现 
象 ， 比 如 下 面 这 个 例子 。 

我 找到 了 一 个 重 传 包 的 序号 为 491， 其 Seq 号 为 349974， 便 以 此 作 
为 过 滤 条 件 ， 如 图 1 所 示 。 


Filter: | tcp,seq == 349974 -| Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
491 7.425781 Client Server TCP [TCP Fast Retransmission] 65096-~8888 [ACK] Seq=349974 Ack=277 W 


492 7.425781 Server Client TCP [TCP Dup ACK 486#4] 8888-65096 [ACK] Seq=277 Ack=349974 Win=409 
493 7.425781 Server Client TCP 8888-65096 [ACK] Seq=277 Ack=351362 Win=4096 Len=0 TSval=295503 
< I 


日 Transmission Control Protocol, src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 349974, Ack: 277 
source Port: 65096 (65096) 
Destination Port: 8888 (8888) 
[stream index: 0] 
[TCP Segment Len: 1388] 


Sequence number: 349974 (relative sequence number) 
[Next sequence number: 351362 (relative sequence number)] 
Acknowledgment number: 277 (relative ack number) 

图 1 


点 击 Apply 过 减 ， 可 十 绪 采 却 只 见 重 传 包 ， 不 见 原始 包 ， 如 图 2 所 
示 。 是 什么 原因 导致 了 这 个 现象 呢 ? 


Filter | tcp.seq == 349974 [= | Eepression.. Clear Apply Save 
b Time Source Destination Protocol Info 
491 7.425781 Client Server TCP [TCP Fast Retransmission] 65096-8888 [ACK] Seq=349974 Ack=277 Win=65535 Len=1388 


LL 
3 Transmission Control Protocol, src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 349974, ACk: 277, Len: 1388 
Source Port: 65096 (65096) 
Destination Port: 8888 (8888) 
[stream index: 0] 
[TCP Segment Len: 1388] 
sequence number: 349974 (relative sequence number) 
[Next sequence number : 351362 (relative sequence number)] 
Acknowledgment number: 277 (relative ack number) 


图 2 
一 般 有 下 面 3 个 可 能 
是 在 接收 方 抓 的 ， 看 不 到 已 经 在 路 上 丢失 的 原始 包 是 正常 
的 ; 


:开始 抓 包 的 时 候 ， 原 始 包 已 经 传 完了 ， 看 不 到 它 也 是 合理 的 ; 


-Wireshark 出 了 bug ， 把 一 个 正常 包 标 记 成 | TCP Fast 
Retransmission| 了 。 


不 过 我 遇 到 的 情况 并 不 符合 这 3 个 可 能 。 原 始 包 实际 上 已 经 抓 到 
了 ， 只 是 用 它 的 Seq 号 过 滤 不 出 来 而 已 。 

我 是 怎么 知道 原始 包 已 经 抓 到 的 呢 ? 请 看 图 3， 我 把 过 滤 条 件 改 成 
“tcp.sed<349974”， 发 现 客户 端 最 后 发 送 的 一 个 包 是 “Seq=348586 ， 
Len=2776”， 正 好 包含 了 我 们 想 要 寻找 的 原始 包 “Seq==349974 ， 
Len=1388” 的 所 有 字 节 。 


Filter | tcp.seq < 349974 [= | Expression.. Clear Apply Save 


No,. Time Source Destination Protocol Info 
| 129 3.023437 Client Server TCP 65096-8888 [ACK] Seq=348586 Ack=l Win=65535 Len=2776 
4 Tm 


日 Transmission Control Protocol, src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 348586, 
source Port: 65096 (65096) 


Destination Port: 8888 (8888) 
[Stream index: 0] 


[TCP Segment Len: 2776] 


sequence number : 348586 (relative sequence number) 
[Next sequence number: 351362 (relative sequence number)] 
Acknowledgment number: 1 (relative ack number) 


图 3 
我 一 开始 觉得 很 奇怪 ， 这 个 TCP 连 接 的 MSS (最 大 数据 段 长 度 ) 是 
1388， 怎 么 会 有 Len=2776 ( 即 1388 的 两 倍 ) 的 包 出 现 呢 ? 后 来 读 到 了 


Wikipedia 上 的 一 个 条 目 ， 才 知道 这 就 是 传说 中 的 LSO (Large Segment 
Offload) 。 目 前 我 还 没有 听 到 过 “ 信 达 雅 ” 的 翻译 ， 所 以 还 是 以 LSO 来 称 
呼 它 吧 。 

LSO 是 什么 昵 ? 它 是 为 了 拯救 CPU 而 出 现 的 一 个 创意 。 随 着 网 络 进 
入 和 干 睁 和 万 兆 时 代 ，CPU 的 工作 负担 明显 加 重 了 。625MB/s 的 网 络 流量 
大 约 需 要 耗费 5 GHz 的 CPU， 这 已 经 需要 一 个 双核 2.5 GHz CPU 的 全 首 
处 理 能 力 了 。 为 了 缓解 CPU 的 压力 ， 最 好 把 它 的 一 些 工 作 外 包 

(offload) 给 网 卡 ， 比 如 TCP 的 分 段 工作 。 

传统 的 网 络 工作 方式 是 这 样 的 :应 用 层 把 产生 的 数据 交 给 TCP 层 ， 
TCP 层 再 根据 MSS 大 小 进行 分 段 (由 CPU 负责 ) ， 然 后 再 交 给 网 卡 。 而 
启用 LSO 之 后 ，TCP 层 就 可 以 把 大 于 MSS 的 数据 块 直接 传 给 网 卡 ， 让 网 
卡 来 负责 分 段 工 作 了 。 比 如 本 例子 中 的 “Seq=348586，Len=2776”， 最 
百 会 被 网 卡 分 成 <Seq=348586，Len=1388” 和 “Seq=349974，Len=1388” 
两 个 包 。 由 于 在 发 送 方 抓 包 时 相当 于 站 在 CPU 的 视角 ， 所 以 看 到 的 是 
一 个 分 段 前 的 大 包 。 假 如 是 在 接收 方 抓 包 ， 就 是 网 卡 分 段 后 的 两 个 小 
包 了 .BSI 。 本 文 用 到 的 这 个 例子 还 是 比较 小 的 数据 块 ， 我 还 经 常 抓 到 比 
这 个 大 十 倍 以 上 的 。 前 几 天 @ 阿 里 技术 保障 还 在 微 博 上 发 了 一 篇 文 
莫 ， 也 介绍 了 这 个 技术 。 

在 过 去 几 年 中 ， 我 经 常 在 估算 拥塞 点 时 遭遇 LSO， 这 就 需要 先 想 
象 出 它 分 段 后 的 样子 ， 然 后 再 用 老 办 法 计算 。 我 也 有 过 多 次 利用 LSO 
做 性 能 调 优 的 经 历 ， 比 如 VMware 上 的 虚拟 网 卡 有 时 候 是 性 能 瓶颈 ， 关 
闭 LSO 反 而 性 能 会 更 好 。LSO 的 配置 方式 很 简单 ，Windows 上 只 需要 在 
网 卡 的 高 级 属性 中 找到 Large Send Offload 项 就 行 了 ( 见 图 4) 。 


nt 


tie 


The following properties are available for this network adapter. Click 
the property you want to change on the left, and then select ts value 


我 在 离开 交大 之 前 ， 特 意 从 校内 FTP 下 载 了 很 多 资料 ， 包 括 RFC 文 
档 。 其 实 当 时 并 没有 阅读 它们 的 打算 ， 只 是 想 存 在 电脑 里 ， 以 备 不 时 
之 需 。 不 过 工作 了 几 年 后 ， 我 开始 意识 到 RFC 不 只 是 用 来 检索 的 。 对 
于 最 棘手 的 那 部 分 网 络 问题 ， 有 时 必须 吕 读 RFC 才 能 解决 ， 我 手头 残 
有 很 多 例子 可 以 证 明 这 一 点 。 

老 油条 的 工程 师 都 知道 ， 性 能 问题 是 最 难 的 ， 因 为 没有 任何 报错 
可 以 入 手 ， 我 们 就 来 说 一 个 性 能 相关 的 案例 吧 。 有 家 公司 跟 我 反映 过 
这 样 一 个 问题 ， 他 们 的 客户 端 发 数据 到 国外 服务 器 时 非常 慢 。 慢 到 什 
么 程度 呢 ? 连 期 望 值 的 一 半 都 达 不 到 ， 就 像 你 家 里 租 了 100M 和 带宽， 但 
实际 用 起 来 却 不 到 5M 的 效果 ， 肯 定 会 不 满意 。 现 实 中 这 类 问题 往往 是 
这 样 收场 的 : 

用户 向 运营 商 投诉 带宽 不 足 ; 

:运营 商用 测速 工具 自 证 清 日 ; 

用户 掏 钱 租用 更 多 市 视 。 

其 实用 不 着 多 花 钱 ， 用 Wireshark 仔 细 分 析 一 下 ， 基 本 都 能 找到 提 
升 性 能 的 方法 。 我 先 在 客户 端 抓 了 个 包 ， 然 后 尝试 了 惯用 的 三 板斧。 

1， 在 Wireshark 的 Analyze 一 Expert Info ~ Notes 荣 单 中 看 到 图 1 的 重 
传统 计 ， 上 万 个 包 中 只 有 7 个 需要 重 传 ， 比 例 不 算 高 。 


TAN rr 5S) 


医 9 AP 
是 Wireshark: 361 ExpertInfos 0 WA 


| Errors: 0 (0) [Warnings: 2 03) | Notes: 12 (58) |Chats: 0 (0) | Details: 361 | Packet Comments: 0 


Group 4 Protocol 4 Summary 4 Count 


由 Sequence TCP This frame is a (suspected) retransmission 
由 Sequence TCP Duplicate ACK (#3) 
由 Sequence TCP Duplicate ACK (#4) 


四] Limitto display filter 


Help 


2. 点 击 一 个 来 自 服务 器 的 Ack 查 看 往返 时 间 (RTT) 。 J 
可 见 ， 大 概 是 78 晕 秒 。 我 随机 点 击 了 很 多 个 Ack， 都 差不多 是 这 个 值 。 


No, _ Time Source Destination Protocol Info 
63 0.394531000 Client server TCP 58512-8888 [ACK] Seq=699075 Ack=829 Win=65535 Len=38304 
64 0.394531000 Client server TCP 58512-8888 [ACK] Seq=737379 Ack=829 Win=65535 Len=1000 
65 0.394531000 Server Client TCP 8888-58512 [ACK] Seq=829 Ack=630006 Win= 19660 Len=0 TSV 


mm 


习 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
习 [SEQ/ACK analysis] 


hls a0 AeK torhe seonent 1 fas) scoras] 
图 2 

收集 完 这 些 信 息 束 可 以 初步 分 机 了 : 丢 包 不 多 ，RIT 也 很 稳定 ， 但 
数据 却 传 不 快 。 难 道 是 客户 端的 TCP 发 送 窗 口 太 小 了 吗 ? 说 到 这 里 就 需 
要 补充 点 基础 知识 了 : 决定 客户 端 发 送 窗 口 的 因素 有 两 个 ， 分 别 为 网 
络 上 的 拥塞 窗口 pe Window， 缩 写 为 cwnd) 和 服务 器 上 的 接 
收 窗口 。 后 者 与 本 案例 无 关 (已 经 大 到 可 以 忽略 ) ， 而 且 在 本 书 的 
《技术 与 工龄 》 一 文中 详细 介绍 了 人 ， 这 里 就 不 再 改 述 。 本 文 要 讲 的 是 
更 有 技术 含量 的 cwnd， 学 过 TCP 协 议 的 工程 师 都 知道 ，cwnd 的 增长 方 
式 是 先 “ 慢 局 动 ”， 然 后 再 进入 “拥塞 避免 ”。 前 者 起 点 低 但 能 快速 增长 ; 
后 者 起 点 高 ， 但 是 每 个 RIT 只 能 增加 一 个 MSS (Maximum Segment 
Size, 表示 一 个 TCP 包 所 能 携带 的 数据 量 ) 。 在 坐标 轴 中 是 这 样 表示 
cwnd 的 增长 过 程 的 ， 见 图 3。 


Time 


图 3 

了 解 完 基础 知识 ， 我 们 再 回头 看 看 Wireshark 里 的 cwnd。 选中 一 个 
发 送 窗口 中 最 后 的 那个 包 ， 就 可 以 看 到 它 的 “Bytes in flight”， 它 在 本 案 
例 中 束 代 表 了 cwnd 的 大 小 。 我 随机 选中 了 1970 号 包 ， 从 图 4 可 见 其 cwnd 
为 76020。 根 据 图 3 的 理论 ， 如 果 当 时 处 于 “拥塞 避免 ?阶段 ， 那 下 一 个 
cwnd 应 该 就 是 76020 加 上 一 个 MSS 〈 以 太 网 中 大 概 为 1460 字 节 ) ， 变 成 
77480。 如 果 是 在 慢 启 动 阶段 ， 那 就 远 远 不 止 这 么 大 。 


No， Time Source Destination Protocol Info 


1969 17.437500000 Client server TCP 58512-8888 [ACK] Seq=24207689 Ack=25393 Win=65535 Le 
Es70|17.437500000 client server TCP 58512-8888 [ACK] Seq=24225473 Ack=25393 Win=65535 Le 
1971 17.449219000 server Client TCP 8888-58512 [PSH, ACK] Seq=25393 Ack=24150038 Win=196 
1972 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24207494 Win=19660 Le 
1973 17.515625000 Client server TCP 58512-8888 [ACK] Seq=24226058 Ack=25669 Win=65535 Le 
1974 17.515625000 Client server TCP 58512-8888 [ACK] Seq=24283514 Ack=25669 Win=65535 Le 
1975 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24226058 Win=19660 Le 


I4 | 有 


Urgent pointer: 0 
田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
互 [SEQ/ACK analysis] 
[Bytes in flight: 76020] 


图 4 

im i aid 包 ) 的 cwnd 
为 76215。 也 就 是 说 经 历 了 一 个 RTT 之 后 才 增 加 了 195 个 字 节 ， 远 不 如 我 
1 
客户 端的 发 送 窗口 增长 非常 慢 ， 所 以 传输 效率 就 很 低 。 


No. _ Time Source Destination Protocol Info 

1969 17.437500000 Client server TCP 58512-8888 [ACK] Seq=24207689 Ack=25393 Win=65535 
1970 17.437500000 Client server TCP 58512-8888 [ACK] Seq=24225473 Ack=25393 Win=65535 
1971 17.449219000 server Client TCP 8888-58512 [PSH, ACK] Seq=25393 Ack=24150038 Win=] 
1972 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24207494 Win=19660 
1973 17. 515625000 Client server TCP 58512-8888 [ACK] Seq=24226058 Ack=25669 Win=65535 
17.515625000 Client server TCP 58512-8888 [ACK] Seq=24283514 Ack=25669 Win=65535 
1975 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24226058 Win=19660 


二 有 
| Urgent pointer. U 


田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
s [SEQ/ACK analysis] 


| Bytes ln tilight: 76215 


图 5 

性 能 差 的 原因 终于 找到 了 ， 但 是 客户 端 为 什么 会 有 这 种 诡异 的 表 
现 呢 ? 更 神奇 的 和 是， 同样 的 客户 端 发 数据 给 其 他 服务 器 就 没有 这 个 问 
题 ， 因 此 我 们 还 不 能 把 问题 根源 定位 到 客户 端 上 。 当 你 百 思 不 得 其 解 
的 时 候 ， 最 好 是 去 代码 里 看 看 cwnd 的 计算 方式 是 不 是 有 问题 。 但 如 果 
没有 客户 端的 代码 ， 或 者 根本 看 不 慌 代 码 呢 ? 熟 读 RFC 的 优势 就 体现 
出 来 了 。 在 RFC5681 中 讲 到 了 多 种 cwnd 的 计算 方式 ， 其 中 有 一 种 是 这 
样 的 : 


Another common formula that a TCP MAY use to update cwnd during 


congestion avoidance is given in equation (3): 


cwnd+=MSS*MSS/cwnd (3) 

单 看 公式 不 太 容 易 理 解 ， 用 人 话 解 释 一 下 就 是 这 样 的 :假如 客户 
端的 当前 cwnd 大 小 为 n 个 MSS， 它 就 会 在 一 个 窗口 里 发 出 去 n 个 包 ， 然 
后 期 望 收 到 n 个 Ack。 每 收 到 1 个 Ack 它 就 把 cwnd 增 加 
“MSS*MSS/cwnd”， 于 是 收 到 n 个 Ack 之 后 就 总 共 增 加 了 “MSS* 
(n*MSS/cwnd)”。 由 于 cwnd 等 于 n 个 MSS， 所 以 括号 里 的 (n*MSS/cwnd) 
大 约 等 于 1， 从 而 实现 了 每 经 过 1 个 RTT 就 增加 1 个 MSS 的 目的 。 

假如 客户 端 采用 的 就 是 这 个 算法 ， 那 的 确 是 可 能 导致 cwnd 增 长 过 
慢 的 ， 因 为 它 只 有 在 收 到 n 个 Ack 的 情况 下 才能 按 预 期 增长 ， 而 世界 上 
并 非 每 台 服 务 器 都 是 收 到 n 个 数据 包 就 回复 n 个 Ack 的 。 我 实验 室 中 的 
Linux 服 务 器 就 是 累计 收 到 两 个 数据 包 才 Ack 一 次 ， 这 丈 意 味 着 客户 端 
每 经 过 1 个 RTT 只 能 增长 /2 个 MSS。 可 是 即使 这 样 也 比 我 手头 的 案例 好 
得 多 啊 ，195 个 字 节 还 不 到 17 个 MSS 呢 。 这 说 明 Ack 的 频率 非常 之 低 ， 
在 Wireshark 里 也 很 容易 证 实 这 一 点 。 

于 是 这 个 问题 就 转换 为 如 何 提 高 服务 器 的 Ack 频 率 了 。 几 番 搜 索 之 
后 ,我们 发 现 这 台 服 务 器 的 网 卡 上 启用 了 Large Receive Offload 

(LRO) ， 会 积累 多 个 TCP 包 再 集中 处 理 ， 因 此 Ack 数 就 比 别 的 服务 器 
少 很 多 ， 这 也 解释 了 为 什么 其 他 服务 器 没有 性 能 问题 。 后 来 系统 管理 
员 用 ethtool 命 令 关闭 LRO 就 把 问题 解决 掉 了 。 

总 结 下 来 ， 本 和 案例 中 的 客户 端 采 用 了 一 种 不 太 科 学 的 cwnd 算 法 ， 
服务 器 上 又 启用 了 LRO“。 两 者 分 开工 作 的 时 候 都 没有 问题 ， 但 是 配合 
起 来 束 会 导致 cwnd 上 升 过 慢 ， 从 而 极 大 地 影响 了 性 能 。 这 类 问题 如 果 
没有 Wireshark ， 我 们 估计 都 无 法 定位 ， 而 如 果 不 熟 读 RFC， 束 算 用 上 
Wireshark 也 不 知道 如 何 解决 。 怠 像 武侠 小 说 里 的 内 力 和 剑 法 一 样 ， 两 
者 都 很 重要 。 


很 多 年 来 ，IT 公 司 的 笔试 试卷 中 都 有 这 样 一 道 送 分 题 一 一 列举 TCP 
和 UDP 的 差别 。 我 遇 到 过 的 应 聘 者 或 多 或 少 都 能 答 出 重点 ， 比 如 TCP 是 
可 靠 的 ，UDP 是 不 可 靠 的 ， 等 等 ， 有 些 甚至 能 把 教材 中 的 段落 原封 不 
动 地 写 出 来 。 

不 过 我 最 近 开 始 怀疑 这 道 笔试 题 的 价值 ， 因 为 很 多 人 似乎 是 死记 
人 硬 背 的 ， 完 全 不 理解 答案 的 真正 舍 义 。 就 算 有 部 分 人 说 得 出 个 所 以 
然 ， 也 不 知道 如 何 运 用 。 本 文 要 分 享 的 案例 ， 就 是 关于 TCP 和 UDP 的 差 
别 。 

故事 的 背景 是 这 样 的 ， 某 公司 的 主 数据 中 心 设 在 上 海 ， 通 过 网 络 
把 数据 同步 到 北京 的 镜像 ， 每 10 分 钟 同步 一 次 。 项 目 实施 时 规划 得 很 
好 ， 租 用 的 带宽 经 过 严密 计算 所 以 理论 上 完全 满足 需求 ， 也 用 FTP 传 输 
验证 过 了 。 可 是 不 知道 为 什么 ， 实 施 后 却 无 法 在 10 分 钟 内 完成 数据 同 
步 。 实 施 团队 驻 场 数 天 都 没有 人 解决， 只 能 怀疑 租用 的 宽带 质量 有 问 
题 ， 于 是 就 和 网 络 提 供 商 陷入 了 无 休止 的 扯皮 。 

到 最 后 实在 走投无路 了 ， 项 目 组 决定 抓 一 个 网 络 包 来 分 析 ， 便 找 
到 了 我 。 我 拿 到 包 之 后 和 党 试 了 惯用 的 三 板 竹 ， 可 惜 没 有 发 现任 何 异 
毅 ， 于 是 只 能 检查 其 他 方面 的 信息 了 。 

1. 扣 击 Wireshark 的 Statistics 菜 单 ， 再 点 击 Conversations， 见 图 1 。 
志 UDP.pcap [Wireshark 1.12.2 (W1122-0 To master-1 1 
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图 1 


No. Tirme Source Destin’ Brotocol Hierarchy 
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2， 从 TCP 标 签 可 见 传输 的 数据 量 (Bytes) 极 少 ， 见 图 2。 
| Ethemet: 1| Fibre Channel | FDDI] | IPvd: 1 | Ipv6| Ipx| JXTA| Ncp| Rsypj SGJP| TCP: 32 okEn Ring| UDP: 引 US 


TCP Conversations 
Addre 4 PortA 4 AddressB 4 PortB 4 Packets 4 Bytes  ™ Packets A—=B 4 Bytes A—B 4 Packets A~B4 B 
Beijing 33871] Shanghai 535040 945 158 992 472 123 006 473 
Beijing 49871] Shanghai 5040 503 76 646 251 55 494 252 
Beijing 39355 Shanghai 5040 455 68 310 227 48 666 228 
Beijing 60163 Shanghai 5040 441 65 984 220 46 926 221 
Beijing 35123 Shanghai 5040 437 的 253 218 46 155 219 
Beijing 51709 Shanghai 5040 436 65 061 218 46 287 218 
图 2 


3， 再 看 UDP 标签 ， 发 现 传输 的 数据 量 (Bytes) 明显 大 得 多 ， 见 图 
3 


Ethernet: 1 | Fibre Channel| FDD] | IPvA: 1 | IPv6 | IPX | JXTA | NEP | RSVP | SETP | TCP: 52| Token Ring| UDP': 5 


UDP Conversations 
Address A 4 PortA 4 Address B 4 PortB 4 Packets 4 Bytes 4 Packets A—B 4 Bytes A—=B 4 Packets A—B4 上 


shanghai 5204 Beijing 5204 473 434 4d] 623 226 415 984 37871 149 57 450 

Beljing 5203 shanghai 5202 10 533 695 178 5225 344 850 5 308 

shanghai 5203 Beiljing S202 10 531 695 046 5307 350 262 5 224 

shanghai 5040 Beljing 5040 B45 113 210 425 56 946 420 
图 3 


以 上 的 初步 分 析 表 明 数 据 是 通过 UDP 传 输 的 ， 而 根据 UDP 在 广 域 
网 中 一 贯 的 不 靠 谱 表现 (并 不 是 说 UDP 这 个 协议 本 身 不 靠 谱 ， 而 是 很 
多 基于 UDP 的 应 用 程序 没有 做 好 性 能 优化 ) ， 我 认为 这 一 点 需要 着 重 
研究 。 于 是 我 又 粗略 看 了 一 下 Wireshark 的 主 窗口 ， 果 然 发 现 很 多 图 4 这 
样 的 报错 。 


Fiter icmp 加 Expression... Clear Apply Save 


Neo. Time Source Destination Protocol Info 
404394 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404395 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404396 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404397 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404578 117.994370 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404802 118.762281 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543888 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543889 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543890 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543891 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543892 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543893 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543948 201.440730 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549061 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549062 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549063 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 


图 4 
这 个 报错 很 常见 ， 在 1981 年 公布 的 RFC 792 束 有 介绍 本: 


If a host reassembling a fragmented datagram cannot complete the 


reassembly due to missing fragments within its time limit, it discards the 
datagram，and it may send a time exceeded message. ( 当 接 收 方 因 为 分 片 
丢失 而 无 法 按时 完成 数据 包 的 重组 时 ， 它 可 以 放弃 并 回复 一 个 超时 消 
局 起 ， 

也 就 是 说 ， 从 上 海 发 往 北 京 的 UDP 数 据 包 被 分 片 传输 了 。 但 由 于 
有 些 分 片 在 路 上 丢失 ， 导 致 北京 一 方 无 法 完成 重组 ， 所 以 就 出 现 了 图 4 
中 的 报错 ， 过 程 如 图 5 所 示 。 


-个 UDP 数据 包 被 切 成 6 个 分 片 


> 于 = 
ra X 第 6 个 分 片 丢 失 北京 方 无 法 组 装 这 些 
分 片 , 所 以 不 响应 


上 海 方 等 不 到 响应 ， 
所 以 从 头 再 传 一 次 


北京 方 的 啊 应 


图 5 

从 中 可 见 一 个 分 乒 的 丢失 ， 会 导致 所 有 分 搬 都 被 重 传 一 过， 效率 
极 低 。 这 个 例子 说 明了 UDP 不 能 把 大 块 数据 先进 行 分 段 ， 所 以 很 容易 
被 网 络 层 分 乒 ; 也 说 明了 UDP 是 不 可 靠 的 ， 它 缺乏 一 个 机 制 来 确 傈 数 
据 被 安全 送 达 ， 所 以 只 能 由 应 用 层 来 负责 重 传 。 

找到 了 根本 原因 ， 解 决 起 来 殉 好 办 了 “。 在 研发 人 员 能 够 优化 UDP 
传输 之 前 (技术 上 也 是 可 以 做 到 的 ) ， 我 建议 把 传输 层 换 成 TCP， 这 样 
理论 上 能 大 幅度 提高 性 能 。 理 由 如 下 。 

-TCP 有 拥塞 控制 机 制 ， 能 够 降低 网 络 拥塞 时 丢 包 的 概率 。 这 一 扩 
细 说 起 来 太 复杂 ， 有 兴趣 的 读者 可 参考 我 的 上 一 本 书 的 70 一 79 页 ， 本 
文 束 不 发 述 了 。 

即便 在 丢 包 概率 一 样 的 情况 下 TCP 也 有 优势 ，TCP 的 分 段 机 制 可 
以 把 数据 拆 小 后 封装 在 多 个 包 里 ， 避 人 免 了 被 网 络 层 分 片 。 重 传 TCP 包 的 
效率 可 比重 传 分 片 高 多 了 。 比 如 同样 大 小 的 数据 块 分 成 6 个 TCP 包 传 
输 ， 同 样 只 丢失 了 最 后 一 个 ， 重 传 过 程 如 图 6 所 示 。 


同一 块 数据 被 分 成 6 个 TCP 包 发 送 


CE > XK 第 6 个 TcP 包 于 失 
Ack 前 5 个 TcP 包 


上 海 方 等 不 到 第 6 个 包 的 Ack， 
所 以 决定 重 传 它 
北京 方 的 响应 


图 6 

可 见 TCP 只 需要 重 传 丢失 的 那 一 个 包 ， 而 不 是 所 有 包 ， 所 以 效率 比 
重 传 分 片 高 多 了 。 在 传输 过 程 中 应 用 层 也 不 用 负责 重 传 事宜 ， 因 为 TCP 
是 可 靠 的 ， 能 确保 数据 被 安全 送 达 。 本 文 的 例子 中 只 用 了 6 个 包 ， 所 以 
对 比 还 不 够 明显 。 假 如 一 块 数据 要 切 成 50 个 包 来 传 ， 那 TCP 的 优势 就 更 
能 体现 出 来 了 。 

项 目 组 按照 我 的 建议 改 成 TCP 之 后 ， 性 能 果然 就 上 去 了 。 因 此 这 个 
问题 本 质 上 就 这 么 人 简单， 每 一 个 过 得 了 笔试 的 人 本 应 该 都 会 的 。 从 课 
本 知识 到 实际 应 用 之 间 ， 只 差 一 个 Wireshak 来 牵线 搭桥 。 

当然 了 ， 千 万 不 要 因为 这 个 案例 束 否 定 UDP 的 价值 ， 还 记得 我 上 
本 书 提 到 DNS 查 询 的 例子 吗 ? UDP 在 那 种 场合 就 是 领先 的 。 即 使 在 本 
文 的 场景 中 ， 只 要 人 研发 团队 给 力 ， 用 UDP 也 可 以 实现 很 好 的 性 能 。 争 
论 TCP 和 UDP 哪 个 更 好 ， 就 像 百度 贴吧 每 天 在 吵 狮 子 和 老虎 谁 更 厉害 一 
样 元 聊 。 它 们 俩 都 症 其 领域 之 王 ， 只 不 过 一 个 适合 在 草原 ， 男 一 个 适 
合 在 森林 而 已 。 


上 篇 文章 《一 个 你 本 该 能 解决 的 问题 》 被 一 些 技术 圈 的 朋友 转载 
后 ， 收 到 了 不 少 网 友 提问 。 我 从 中 挑 了 几 个 最 有 代表 性 的 ， 在 本 文 一 
并 回答 了 ， 希望 也 是 你 感 兴趣 的 。 

问题 1: 为 什么 要 分 片 ? 

20 世 纪 60 年 代 以 前 ， 数 据 通 信 是 依靠 电路 交换 技术 的 ， 根 本 没有 
分 片 一 说 ， 比 如 传统 电话 。 由 于 电路 交换 的 双方 要 独占 链 路 ， 所 以 利 
用 率 很 低 ， 直 到 Paul Baran 和 Donald Davies 发 明了 分 组 交换 的 概念 ， 把 
数据 分 割 成 小 包 后 才 实现 了 链 路 共享 。 既 然 要 分 割 ， 怠 得 先 确 定 一 个 
包 的 大 小 ， 有 趣 的 是 当时 这 两 位 独立 发 明 人 都 在 实验 室 中 选择 了 128 字 
节 作 为 一 个 传输 单位 。 不 过 到 了 20 世 纪 80 年 代 的 以 太 网 中 ， 就 发 展 到 
以 1500 字 节 作 为 最 大 传输 单位 了 ， 即 MTU (Maximum Transmission 
Unit) 为 1500。 刨 去 20 字 节 的 头 部 ， 一 个 卫 包 最 多 可 以 携带 1500- 
20=1480 字 节 的 数据 。 当 要 传输 的 数据 块 超过 1480 字 方 时 ， 网 络 层 就 不 
得 不 把 它 分 片 ， 封 装 成 多 个 网 络 包 。 

问题 2 发 送 方 是 怎样 确定 分 片 大 小 的 ? 

一 般 来 说 ， 发 送 方 是 依据 自身 的 MTU 来 决定 分 片 大 小 的 。 图 1 演示 
了 一 块 数据 被 MTU 为 1500 的 发 送 方 分 割 成 了 23 个 分 厂 的 样子 。 我 们 可 
以 从 “off=0”、“off=1480”、“off=2960” 等 偏 移 量 计算 出 这 些 分 片 所 携带 
的 数据 量 都 为 1480 字 市 ， 和 问题 1 中 的 分 析 一 致 。 


No. Time 


Source 


Destination Protocol Info 
IPv4 


7 0.003174 Client Server Fragmented IP protocol (proto=UDP 17, off=0, ID=008c) [Reassembled in #29] 

8 0.003182 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=1480, ID=008c) [Reassembled in #29] 

9 0.003186 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=2960, ID=008c) [Reassembled in #29] 

10 0.003189 Client server IPv4 Fragmented IP protocol (proto=UDP 17, off=4440, ID=008c) [Reassembled in #29] 

11 0.003191 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=5920, ID=008c) [Reassembled in #29] 

12 0.003194 Client server IPv4 Fragmented IP protocol (proto=UDP 17, off=7400, ID=008c) [Reassembled in #29] 

13 0.003197 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=8880, ID=008c) [Reassembled in #29] 

14 0.003201 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=10360, ID=008c) [Reassembled in #29] 
15 0.003203 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=11840, ID=008c) [Reassembled in #29] 
16 0.003206 Client Sserver IPV4 Fragmented IP protocol (proto=UDP 17，off=13320，ID=008c) [Reassembled in #29] 
17 0.003208 Client Server IPVv4 Fragmented IP protocol (proto=UDP 17, off=14800, ID=008c) [Reassembled in #29] 
18 0.003211 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=16280, ID=008c) [Reassembled in #29] 
19 0.003213 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=17760，ID=008c) [Reassembled in #29] 
20 0.003216 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=19240, ID=008c) [Reassembled in #29] 
21 0.003219 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=20720, ID=008c) [Reassembled in #29] 
22 0.003222 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=22200, ID=008c) [Reassembled in #29] 
23 0.003224 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=23680，ID=008c) [Reassembled in #29] 
24 0.003227 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=25160, ID=008c) [Reassembled in #29] 
25 0.003230 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=26640, ID=008c) [Reassembled in #29] 
26 0.003233 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=28120, ID=008c) [Reassembled in #29] 
27 0.003236 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=29600, ID=008c) [Reassembled in #29] 
28 0.003238 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=31080, ID=008c) [Reassembled in #29] 
29 0.003240 Client Server NFS V3 WRITE Call (Reply In 142), FH: 0x2823al91 offset: 0 Len: 32768 UNSTABLE 


图 1 

不 过 你 如 果 经 常 分 析 各 种 环境 中 的 包 ， 会 发 现 有 些 分 厂 并 不 是 携 
带 1480 字 有 ， 而 是 更 大 或 者 更 小 。 这 是 因为 有 些 网 络 是 Jumbo Frame 

( 巨 帧 ) 或 PPPOE 之 类 的 ， 它 们 的 MTU 并 不 是 1500。 于 是 问题 来 了 ， 

MTU 不 一 致 的 两 个 网 络 之 间 要 通信 怎么 办 ? 比如 局 用 巨 帧 之 后 的 MTU 
是 9000 字 节 ， 那 从 发 送 方 出 来 的 包 束 有 9000 字 市 ， 万 一 经 过 一 个 MTU 
只 有 1500 字 市 的 网 络 设备 ， 还 是 可 能 被 重新 分 片 甚 至 丢弃 。 这 种 情况 
下 发 送 方 要 怎样 决定 分 片 大 小 ， 才 能 避免 因为 MTU 不 一 致 而 出 问题 
呢 ? 比较 理想 的 办 法 是 先 通过 Path MTU Discovery 协 议 来 探测 路 径 上 的 
最 小 MIU， 从 而 调和 分 片 的 大 小 。 可 殿 该 协议 是 依靠 ICMP 来 探测 的 ， 
会 被 很 多 网 络 设备 禁用 ， 所 以 不 太 可 靠 。 总 而 言 之 ， 目 前 发 送 方 没有 
一 个 很 好 的 机 制 来 确定 最 佳 分 请 大 小 ， 所 以 实施 和 运 维 人 员 配 置 MTU 
时 必须 慎之 又 慎 ， 尽 量 使 网 络 中 每 个 设备 的 MTU 傈 持 一 致 。 在 以 后 的 
文章 中 我 会 分 享 一些 由 于 MTU 配 置 出 错 而 导致 的 问题 。 

问题 3， 接收 方 义 是 徘 什 么 重组 分 厂 的 ? 

假如 分 请 都 到 达 接 收 方 了 ， 要 如 何 重 组 它们 呢 ? 从 图 1 可 见 每 个 分 
片 都 包含 了 “off=xxxx，ID=008c 的 信息 ， 接 收 方丈 是 依据 这 两 个 值 ， 
把 ID 相同 的 分 片 按照 off 值 ( 偏 移 量 ) 进行 重组 的 。 原 理 非 常 简单 ， 唯 
一 的 问题 是 接收 方 如 何 判 断 最 后 一 个 分 片 已 经 到 达 ， 应 该 开始 重组 


了 。 请 看 图 2 所 示 的 最 后 一 个 分 片 ， 也 即 第 29 号 包 ， 它 包含 了 一 个 
“More fragments=0” 的 Flag ， 表 示 它 是 最 后 一 个 分 上 请 ， 因 此 接收 方 可 以 
开始 重组 了 。 


Time Source Destination Protocol Info 
c+* WwwCCI -11 二 IC II VC rv rs JIECIIELEW 二 六 


PI UCUCUS: PI UCU—UUrF LZ/ UI1I 一 < 二 UV 工 LU 一 vv 
25 0.003230 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=26640，ID=008c) 
26 0.003233 Client Server IPv4 Fragmented IP protocol (proto=UDP 17，off=28120，ID=008c) 
27 0.003236 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=29600，ID=008c) 
28 0.003238 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=31080, ID=008cC) 
29 0.003240 Client Sserver NFS V3 WRITE Call (Reply In 142), FH: Ox2823al91 offset: 0 Len 


由 Frame 29: 402 bytes on wire (3216 bits), 402 bytes captured (3216 bits) 
由 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_3f:0d:07 (00:60:16:3f:0d:07) 


日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.72) 
Version: 4 


Header Length: 20 bytes 
田 Differentiated Services Field: Ox00 (DsCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Tr 
Total Length: 388 
Identification: 0x008c (140) 
| 上 日 Flags: 0x00 
= Reserved bit: Not set 
.0.. .... = Don't fragment: Not set 


图 2 

而 其 他 的 分 片 ， 比 如 图 3 的 28 号 包 却 包含 了 一 个 “More fragments=1” 
的 Flag， 因 此 接收 方 知道 后 续 还 有 更 多 分 片 ， 所 以 先 缓存 着 不 重组 。 有 
一 个 网 络 攻 击 方式 就 是 持续 发 送 “More fragments” 为 1 的 包 ， 导 致 接收 方 
一 直 绥 存 分 片 ， 从 而 耗 尽 内 存 。 


No. Time Source Destination Protocol Info 
所 证 Www CC7 TIIL “JC Vor Fv rs QaYynciic cu rr PP WELL IE API WE 一 OUUOF £1) WE 一 到 JUWV 二 EL 一 VVOC 
25 0.003230 Client Server IPv4 Fragmented IP protocol (proto=UDP 17，off=26640，ID=008c) 


26 0.003233 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=28120, ID=008c) 
27 0.003236 Client Server IPv4 Fragmented IP protocol (proto=UDP 17，off=29600，ID=008c) 
28 0.003238 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=31080, ID=008cC) 


由 Frame 28: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
由 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_3f:0d:07 (00:60:16:3f:0d:07) 


日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.72) 
Version: 4 


Header Length: 20 bytes 
田 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable T 
Total Length: 1500 
Identification: 0x008c (140) 
日 Flags: Ox01 (More Fragments) 
0... .... = Reserved bit: Not set 
.0.. .... = Don't fragment: Not set 


图 3 

问题 4 TCP 是 如 何 避 人 免 补 发送 方 分 厂 的 ? 

TCP 可 以 避免 钻 发 送 方 分 片 ， 是 因为 它 主 动 把 数据 分 成 小 段 再 交 给 
网 络 层 。 最 大 的 分 段 大 小 称 为 MSS (Maximum Segment Size) ， 它 相 


当 于 把 MTU 刨 去 IP 尖 和 TCP 头 之 后 的 大 小 ， 所 以 一 个 MSS 愉 好 能 装 进 
一 个 MTU 中 。 
MTU 


MSS 


图 4 

图 4 演示 了 MSS 和 MTU 的 关系 。 有 的 时 候 TCP 头 不 只 20 字 方 ， 所 以 
会 侵占 一 些 MSS 的 空间 ， 比 如 图 5 的 例子 中 就 占用 12 字 节 作 为 TCP 
Options， 那 传输 层 真正 用 来 承载 数据 的 束 剩 下 1500-20-20-12=1448 字 下 
了 。 这 些 字 节 数 都 能 在 Wireshark 中 看 到 。 这 就 是 为 什么 我 回 网 络 教师 
们 大 力 推荐 Wireshark， 演 示 时 真是 一 目 了 然 。 


田 Frame 58: Es14] bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
由 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_2b:5d:b2 (00:60:16:2b:5d:b2) 
日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.62) 
Version: 4 
Header Length: 20 bytes 
Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable Transport)) 
Total Length: 
Identification: 0x8led (33261) 
Flags: Ox02 (Don't Fragment) 
Fragment offset: 0 
Time to live: 64 
Protocol: TCP (6) 
Header checksum: 0xcall [validation disabled] 
source: Client (10.32.106.159) 
Destination: Server (10.32.106.62) 
[source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
9 Transmission Control Protocol, src Port: 706 (706), Dst Port: 2049 (2049), seq: 9133, Ack: 1049, Len: 
source Port: 706 (706) 
Destination Port: 2049 (2049) 
[stream index: 2] 
[TCP segment Len: 1448] 
Sequence number: 9133 (relative sequence number) 
[Next sequence number: 10581 (relative sequence number)] 
Acknowledgment number: 1049 (relative ack number) 
Header Length: 32 bytes 
. 0000 0001 0000 = Flags: Ox010 (ACK) 
Window size value: 694 
[Calculated window size: 22208] 
[window size scaling factor: 32] 
Checksum: Oxf320 [validation disabled] 
Urgent pointer: 0 


options: K12 bytes], No-operation (Nop)，No-operarion (NoP), Timestamps 
图 5 

UDP 则 没有 MSS 的 概念 ， 一 股 脑 交 给 网 络 层 ， 所 以 可 能 被 分 片 。 
分 片 和 重组 都 会 影响 性 能 ， 所 以 UDP 在 这 一 点 上 比 TCP 落 后 一 些 。 


由 


田 


田 


田 


团 


[Ea 


问题 5: 那 TCP 又 是 怎样 适 配 接收 方 的 MTU 的 ? 

问题 4 只 分 析 了 为 什么 TCP 包 不 会 被 发 送 方 的 网 络 层 分 睛 。 那 万 一 
接收 方 的 MTU 比 发 送 方 的 小 怎么 办 ? 比如 发 送 方 启用 了 巨 帧 (Jumbo 
Frame) ， 把 MTU 提 高 到 9000 字 节 ， 但 接收 方 还 停留 在 1500 字 节 的 情 
况 。 这 个 问题 其 实在 我 的 上 一 本 书 中 提 到 过 ，TCP 建 立 连接 时 必须 先进 
行 三 次 握手 (如 图 6 所 示 ) ， 在 前 两 个 握手 包 中 双方 互相 声明 了 自己 的 
MSS， 客 户 端 声明 了 MSS=8960， 服 务 器 声明 了 MSS=1460。 三 次 握手 
之 后 ， 客 户 端 知道 自己 的 MTU 比 服务 器 的 大 ， 如 果 发 一 个 9000 字 闻 的 
包 过 去 很 可 能 在 路 上 就 被 分 片 或 丢弃 。 于 是 在 这 个 连接 中 ， 客 户 端 会 
很 识 相 地 把 自己 的 MSS 也 降 到 1460 字 节 ， 从 而 适 配 了 接收 方 的 MTU 。 


No,. Time Source Destination Protocol Info 

1 0.000000 Client Sserver TCP 33763-111 [SYN] seq=0 Win=17920 Len=0LMss=8960| SACK_PERM=1 
2 0.000000 server Client TCP 111-~33763 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0LMss=1460 
3 0 


003906 Client server TCP 33763-111 [ACK] Seq=1 Ack=l Win=17920 Len=0 TSval=27300530 


图 6 

TCP 在 避免 分 片 这 一 点 上 已 经 做 得 足够 用 心 ， 发 送 方 和 接收 方 都 考 
虚 到 了 。 然 而 网 络 上 的 隐患 防不胜防 ， 假 如 路 径 上 有 个 交换 机 的 MTU 
比 发 送 方 和 接收 方 的 都 小 ， 那 还 是 会 出 问题 。 

问题 6: 为 什么 UDP 比 TCP 更 适合 语音 通话 ? 

如 果 把 UDP 和 TCP 想 象 成 两 位 搬运 工 ， 前 者 的 风格 惑 是 盲目 兰 干 ， 
搬运 过 程 中 丢 了 东西 也 不 管 ， 而 后 者 却 是 小 心 层 缀 ， 丢 了 多 小 的 东西 
都 要 回去 捡 。 假 如 某 个 应 用 环境 允许 忽视 质量 ， 只 追求 速度 ， 那 UDP 
瓯 是 一 个 更 好 的 选择 。 语 音 传输 正 符合 这 种 情况 ， 因 为 它 最 在 乎 的 不 
是 音质 ， 而 是 延迟 。 

采用 UDP 传输 时 ， 如 果 有 些 包 丢失 ， 应 用 层 可 以 选择 忽略 并 继续 
传输 其 他 包 。 由 于 一 个 发 音 会 被 采样 到 很 多 个 包 中 ， 所 以 丢掉 其 中 一 
些 包 只 是 影响 到 了 音质 ， 却 能 保障 流畅 性 。 

而 采用 TCP 传 输 时 ， 出 现 丢 包 就 一 定 要 重 传 ， 重 传 束 会 带 来 延迟 。 
这 是 TCP 与 生 俱 来 的 特点 ， 即 使 应 用 层 想 忽略 丢 包 都 没 办 法 。 前 文 说 过 


TCP 的 优点 是 可 靠 ， 有 丢 包 重 传 机 制 ， 这 个 优点 在 语音 传输 时 束 变 成 了 
缺点 。 通 话 延迟 的 后 果 很 严重 ， 比 如 你 在 语音 聊天 时 对 女神 说 , “这 是 
我 的 头像 ， 牛 吧 ? ”如 琳 在 “ 头 ” 和 “ 像 ” 之 间 恰 好 多 出 一 段 延迟 ， 对 方 听 
上 去 束 可 能 变 成 “这 是 我 的 涉 ， 像 ~~ 牛 吧 ? ”然后 给 你 回 一 句 ，“ 很 像 ! ” 


MTU 9 非 
MTU 带 来 的 问题 实在 太 多 了 ， 但 凡 做 过 运 维 、 实 施 或 者 技术 支持 


的 工程 师 ， 或 多 或 少 都 会 遇 到 。 一 个 典型 的 MTU 问 题 发 生 在 类 似 铭 1 的 
环境 中 ， 即 两 个 子 网 的 MTU 大 小 不 一 样 。 


MTU=1500 


MTU=9000 


客户 端 路 由 器 服务 器 
图 1 


当 客 户 并 发 给 服务 右 的 巨 帧 经 过 路 由 右 时 ， 或 者 被 丢 包 ， 或 者 被 
分 乒 。 这 取决 于 该 巨 帧 是 否 在 网 络 层 携带 了 DEF (Don’t fragment) 标 
志 。 如 采 市 了 吏 和 被 于 痉 ， 如 采 没 市 融和 被 分 睫 。 从 Wireshark 上 很 容易 看 
到 DEF 标志 ， 如 图 2 中 的 方 框 内 所 示 。 分 片 的 情况 往往 被 忽略 ， 因 为 它 只 
影响 一 点 点 性 能 ， 大 多 数 时 候 甚 至 察觉 不 出 。 丢 包 的 情况 就 无 法 忽略 
了 ， 因 为 丢 包 之 后 再 重 传 多 少 遍 都 没 用 ， 会 一 直 和 于， 整个 传输 束 像 挥 
进 了 黑洞 ， 所 以 往往 会 导致 严重 的 后 果 。 


No， Time Source Destination Protocol Info 
1 0.000000000 Client server ICMP Echo (ping) request id=0x0001 ， 
4 | Wm 


Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 1 
由 Ethernet II, Src: Universa_50:a9:f6 (44:39:c4:50:a9:f6), Dst: Cisco_e3:a6:8!( 
日 Internet Protocol Version 4, src: 10.32.200.23 (10.32.200.23), Dst: 10.32.1!( 
Version: 4 


Header Length: 20 bytes 
由 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-E¢ 
Total Length: 1500 
Identification: Ox1314 (4884) 
日 Flags: Ox02 (Don't Fragment) 
0... .... = Reserved bit: Not set 
Don't fragment: Set 
py + 站 扎 守 More fragments: Not set 


图 2 

我 有 个 实验 环境 恰好 就 是 图 1 这 样 的 ， 可 以 来 做 个 实验 加 深 理 解 。 
我 从 客户 端 给 服务 器 发 送 了 两 个 ping 请 求 ， 第 一 个 携带 1472 字 节 ， 第 二 
个 携带 1473 字 市 ， 并 都 用 了 “-f”* 参 数 设 置 了 DF 标志 。 命 令 及 结果 请 看 图 
3， 第 一 个 ping 成 功 ， 第 二 个 则 失败 了 。 


| 画 C\windows\system32xcmdexe “” 量 呈 量 
:\Users\linp1>ping 18.32.186.182 -1 1472 -f -n 1 


pinging 16.32.166.162 with 1472 bytes of data: 
Reply from 16.32.166.162: bytes=1472 time=1lms TTL=251 


Ping statistics for 16.32.196.162: 

Packets: Sent = 1, Received = 1, Lost = 8 (6% loss), 
Approximate round trip times in milli-seconds: 

Minimum = lms, Maximum = lms, Average = 1ms 


:\Users\linp1>ping 18.32.186.182 -1 1473 -f -n 1 


MPinging 18.32.186.182 with 1473 bytes of data: 
Reply from 16.32.266.1: Packet needs to be fragmented but DF set. 


图 3 

由 于 ICMP 头 为 8 字 节 ， 了 PP 头 为 20 字 节 ， 所 以 第 一 个 ping 请 求 在 网 络 
层 的 长 度 为 1472+8+20=1500 字 节 ， 第 二 个 ping 请 求 则 为 
1473+8+20=1501 字 节 。 我 的 路 由 器 MTU 是 1500 字 节 ， 不 难 理解 第 一 个 


ping 请 求 的 长 度 没有 超过 MTU， 所 以 可 以 传输 成 功 ; 而 第 二 个 ping 请 求 
的 长 度 超 过 了 路 由 器 出 口 的 MTU， 又 不 允许 被 切 分 ， 所 以 不 能 传输 成 
功 。 在 图 3 底部 可 以 看 到 路 由 器 提示 了 “Packet needs to be fragmented but 
DF set” ° 

个 过 程 的 网 络 包 可 以 从 图 4 中 看 到 ， 请 注意 最 后 一 个 包 是 路 由 器 
回复 的 “Fragmentation needed”， 而 不 是 服务 器 回复 的 。 假 如 ping 的 时 候 
没有 用 “-f» 设 置 DF 标志 ， 那 么 1473 字 方 也 是 能 ping 成 功 的 ， 只 是 在 路 上 
会 被 切 分 成 两 个 包 。 
es [=]| Expression.. Clear Apply Save 
ee en ee Er ei (ping) request id=0x0001, seq=44/11264, 


1 

3 0.001248000 server Client ICMP Echo (ping) reply id=0x0001，seq=44/11264， 
4 5.311831000 client Server ICMP Echo (ping) request id=0x0001, seq=45/11520, 
3 
| 


4 


5.313062000 Router Client ICMP Destination unreachable (Fragmentation needed) 
和 


* 


田 Frame 4: 1515 bytes on wire (12120 bits), 1515 bytes captured (12120 bits) on interface 0 
四 Ethernet II, Src: Universa_50:a9:f6 (44:39:c4:50:a9:f6), Dst: Cisco_e3:a6:80 (ec:30:91:e3: 
日 Internet Protocol Version 4, src: Client {10.32.200.23), Dst: Server (10. 32.106.102) 
Version: 4 
Header Length: 20 bytes 
田 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Cap 
Identification: Ox132b (4907) 
日 Flags: Ox02 (Don't Fragment) 
0... .... = Reserved bit: SEE Set 


.0. .... = More fragments: Not set 
Fragment offset: 0 
Time to live: 128 
Protocol: ICMP (1) 

国 Header checksum: Ox0000 [validation disabled] 
source: Client (10.32.200.23) 
Destination: server (10.32.106.102) 
[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 

Type: 8 (Echo (ping) request) 

Code: 0 

Checksum: Oxdf1i9 [correct] 

Identifier (BE): 1 (Ox0001) 

Identifier (LE): 256 (Ox0100) 

sequence number (BE): 45 (Ox002d) 

sequence number (LE): 11520 (0x2d00) 


田 [NO response seen] 
I Data (1473 bytes) 


图 4 


理论 说 起 来 很 简单 ， 实 验 做 出 来 也 不 难 ， 但 在 生产 环境 中 的 症状 
就 没 这 么 明显 了 ， 要 发 现 MTU 问 题 往往 需要 一 些 想象 力 。 我 收藏 了 不 
少 MTU 相 关 的 案例 ， 在 本 文 挑 出 三 个 最 有 代表 性 的 来 分 享 。 

案例 1 用 户 浏 咒 菜 些 共 至 目录 时 客户 端 会 死机 ， 浏 览 其 他 目录 则 不 
次 所 

碰 到 这 种 症状 ， 泡 怕 没 有 人 会 想到 是 MTU 导 致 的 ， 所 以 经 过 长 时 
间 徒 劳 无 功 的 排 错 之 后 ， 工 程 师 不 得 不 抓 了 个 包 。 这 个 包 是 在 服务 紫 
上 抓 的 (因为 客户 端 死 机 ， 根 本 没 法 抓 ，， 如 图 5 所 示 ， 服 务 器 回复 的 
包 “Seq=193，Len=1460” 在 持续 重 传 ， 但 客户 闻 一 直 没 有 人 确认， 似乎 是 
发 生 丢 包 了 “。 从 图 5 底部 还 可 以 看 到 这 个 包 携 训 的 信息 是 该 目录 的 子 文 
作 式 类 三 列表 和 


Ne. Time Source Destination Protocol Info 
1 0.000000 Client server SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: 
2 0.000165 Server Client SMB Trans2 Response, QUERY_PATH_INFO 
3 0.008587 Client Server SMB Trans2 Request, QUERY_PATH_INFO, Query File standard Info, Path: 
4 0.008677 Server Client SMB Trans2 Response, QUERY_PATH_INFO 
5 0.011474 Client server SMB Trans2 Request, FIND_FIRST2, Pattern: \* 
6 0.011986 Server Client TCP [TCP segment of a reassembled PDU] 
7 0.011992 Server Client SMB Trans2 Response, FIND_FIRST2, Files: . lost+found .etc Sales TEMP Branch ! 
8 0.033961 Client server TCP [TCP Dup ACK 5#1] 3476-445 [ACK] Seq=251 Ack=193 Win=64289 Len=0_SLE=3113 
9 1.181895 Server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
10 4.178112 Server Client TCP [TCP Retransmission] 445-~3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
11 10.182512 server Client TCP [TcP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
12 22.183406 server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
13 46.185134 server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 


LU 


日 FIND_FIRST2 Data 
四 Find File Both Directory Info File: . 
9 Find File Both Directory Info File: lost+found 
习 Find File Both Directory Info File: .etc 
田 Find File Both Directory Info File: Sales 
田 Find File Both Directory Info File: TEMP 
习 Find File Both Directory Info File: Branch Checklist 
习 Find File Both Directory Info File: Thumbs. db 
四 Find File Both Directory Info File: Ops 
9 Find File Both Directory Info File: PMS 


图 5 

导致 丢 包 的 可 能 性 有 很 多 ， 我 为 什么 认定 是 MTU 导 致 的 呢 ? 推理 
i 

1. 如 采 端 口 被 防火 墙 阻止 了 也 可 能 丢 包 ， 但 是 会 从 三 次 握手 时 束 
开始 丢 ， 而 不 是 等 到 浏览 目 孙 的 时 候 。 

2， 如 果 网 络 拥塞 也 可 能 丢 包 ， 但 一 段 时 间 后 能 恢复 ， 而 不 是 这 样 
持续 地 丢 。 


3. 丢 的 那个 包 携 带 了 1460 字 节 (相当 于 占 满 了 整个 1500 字 节 的 
MTU) ， 算 是 比较 大 的 。 而 没 被 丢弃 的 2 号 包 和 4 号 包 都 携带 了 很 少 的 
字 节 数 ， 只 丢 大 包 的 症状 说 明 很 可 能 就 是 MTU 导 致 的 。 

4. 我 用 “ping<server_ip>-] 1472-f” 测 试 ， 果 然 失 败 了 。 了 逐渐 减 小 每 
次 ping 的 长 度 ， 到 了 1400 字 节 左 右 才 成 功 ， 这 说 明 网 络 上 有 个 设备 的 
MTU 比 较 小 。 

5. 于 是 把 服务 器 上 网 卡 的 MTU 相 应 改 小 ， 问 题 果 然 就 消失 了 。 

6. 之 所 以 浏览 其 他 目录 没有 死机 ， 可 能 是 因为 这 些 目录 中 的 子 文 
件 ( 夹 ) 比较 少 ， 凑 不 满 一 个 大 包 。 

我 曾经 访问 公司 内 网 时 出 现 问题 ， 在 抓 包 里 也 看 到 类 似 于 图 5 的 症 
状 ， 后 来 也 是 通过 修改 MTU 解 决 的 。 

案例 2 客户 问 的 MTU 为 1500 字 节 ， 服 务 器 端的 MTU 为 9000 字 市 ， 
平时 连接 正常 。 运 维 人 员 听 说 两 端的 MTU 最 好 一 致 ， 所 以 把 客户 端的 
MTU 提 高 到 9000 字 节 ， 没 想到 连接 反而 出 问题 了 。 

虽然 该 案例 听 上 去 不 太 科学 ， 但 如 果 网 络 路 径 上 有 个 设备 的 MTU 
是 1500 字 节 ， 这 个 问题 就 真 会 发 生 。 原 先 客户 端 和 服务 器 在 三 次 握手 
时 ， 双 方 会 “协商 ”使 用 一 个 1460 字 节 (MTU-TCP 头 -IP 头 ) 的 MSS， 所 
以 可 以 顺利 通过 那个 MTU 为 1500 的 网 络 设备 。 如 有 果 两 端 都 是 9000 字 市 
了 ， 那 三 次 握手 时 就 会 得 到 8960 字 节 的 MSS， 因 此 通 不 过 那个 网 络 设 
备 o 

案例 3 无 法 完成 Kerberos 喘 份 认 证 ， 在 客户 端 抓 到 的 包 如 网 6 所 
ee 

由 图 6 可 见 客 户 端 在 持续 地 向 KDC 发 送 TGS-REQ， 但 是 收 不 到 任何 
回复 。 本 来 碰 到 这 种 情况 最 好 在 KDC 上 也 抓 个 包 看 看 的 ， 但 是 KDC 一 
般 不 让 人 登 上 去 。 怎 么 办 呢 ? 


No, Time Source Destination Protocol Info 


95 256.218750 Client KDC KRB5 TGS-REQ 
96 261. 218750 Client KDC KRB5 TGS-REQ 
97 261.988281 Client KDC KRB5 TGS-REQ 
98 266.218750 Client KDC KRB5 TGS-REQ 
a3 266.988281 Client KDC KRB5 TGS-REQ 


4 Hh 


User Datagram Protocol, Src Port: 62744 (62744), Dst Port: 88 (88) 
日 Kerberos 
习 站 gs-req 
pvno: 5 
msg-type: krb-tgs-req (12) 
田 padata: 1 item 
日 req-body 
Padding: 0 
I kdc-options: 00000000 


出 


图 6 

从 这 几 个 网 络 包 里 是 挖掘 不 出 更 多 线索 了 ， 我 们 只 能 推测 哪些 因 
素 会 导致 TGS-REQ 得 不 到 回复 。 有 一 个 可 能 是 端口 被 防火 墙 封 控 ， 但 
那样 的 话 之 前 的 其 他 Kerberos 包 (比如 AS-REQ) 也 得 不 到 回复 ， 不 可 
能 走 到 TGS-REQ 这 一 步 ， 因 此 防火 墙 可 以 排除 。 还 有 一 个 可 能 就 是 
MTU 导 致 的 丢 包 了 ， 假 如 网 络 路 人 径 上 有 个 交换 机 的 MTU 仿 小， 大 包 无 
法 通过 就 可 能 出 现 此 证 状 。 仅 从 Wireshark 中 我 们 无 法 判断 是 客户 端 发 
给 KDC 时 丢 包 了 ， 还 是 KDC 回 复 客 户 端 时 丢 包 了 ， 只 能 先 试 着 把 客户 
端的 MTU 改 小 一 点 ， 问 题 果然 束 消 失 了 。 其 实 利 用 “ping-f-]< 字 节 数 >” 
试探 出 路 径 上 的 最 小 MTU 也 可 以 ， 前 提 是 网 络 中 没有 禁用 ICMP 。 


他 


有 位 运 维 人 员 跟 我 讲 了 一 件 趣 事 : 他 有 个 客户 端 连 不 上 某 台 服务 
锅 ， 但 连接 其 他 服务 胡 都 没有 问题 ， 那 台 服 务 句 跟 其 他 客户 端的 通信 


也 很 好 ， 唯 独 遇 到 这 个 客户 端 就 不 行 。 这 种 情况 已 经 不 能 用 排除 法 来 
定位 根源 了 ， 就 好 像 它们 天 生 相 克 一 样 。 

运 维 团队 已 经 研究 了 很 多 天 ， 还 是 毫 无 头绪 ， 于 是 就 在 客户 端 抓 
了 个 包 给 我 分 析 。 从 图 1 可 见 ， 这 个 连接 的 确 出 了 问题 。 具 体 分 析 如 
下 。 

1. 1 号 包 和 2 号 包 是 MAC 地 址 解析 过 程 。 即 客户 端 通过 ARP 广 播 ， 
获得 了 服务 器 的 MAC 地 址 00:15:5d (本 文 只 显示 MAC 地 址 的 前 半 部 


2. 3、4、5 号 包 是 客户 端 向 服务 器 发 起 的 三 次 握手 ， 此 时 看 起 来 
并 没有 问题 。 

3. 6 号 包 是 客户 端 发 给 服务 器 的 数据 ， 但 由 于 服务 器 没有 响应 ， 
所 以 在 7 号 包 重 传 了 一 遇 。 到 这 一 步 已 经 显示 出 传输 问题 了 。 

4. 8 号 包 又 是 来 自 服 务 器 的 [SYN ，ACK]， 表 明 它 是 4 号 包 的 重 
传 。 也 束 是 说 ， 从 服务 器 的 角度 看 ，4 号 包 还 没有 送 达 客 户 端 ， 意 味 着 
三 次 握手 还 没 真正 完成 。 

5， 接 下 来 的 包 仍 然 是 重 传 ， 说 明 它 们 根本 无 法 正常 通信 。 


No. Time Source Destination Protocol Info 


1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 

2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 

3 0.046875 Client Server TCP 51754-389 [SYN] seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 WS=8 

4 0.046875 Server Client TCP 389-51754 mas Ack=1 Win=8192 Len=0 Mss=1460 Ws=256 

5 0.046875 Client Sserver TCP 51754-389 [ACK] seq=1 Ack=1 Win=139264 Len=0 TSval=433697 TSecr 

6 0.046875 Client Server LDAP bindRequest(1) "<ROOT>"” simple 

7 1.156250 Client Server LDAP [TCP Retransmission] bindRequest(1) "<ROOT>" simple 

8 3.058594 Server Client TCP [TCP Spurious Retransmission] 389-51754 [sw seqjseo-o ACck=1 

9 3.058594 Client server TCP [TCP Dup ACK 7#1] 51754-389 [ACK] Seq=15 Ack=1 Win=139264 Len=0 

10 4.156250 Client Server LDAP [TCP Retransmission] bindRequest(1) "<ROOT>" simple 

11 9.070312 Server Client TCP [TCP Spurious Retransmission] 389-51754 seq=0 Ack=1 
图 1 


我 们 能 从 这 个 现象 中 推理 出 什么 呢 ? 至 少 可 以 知道 3 号 包 能 够 到 达 
服务 器 ， 因 此 才 会 有 4 号 包 的 [SYN，ACK]。 但 是 5 号 包 却 没 能 到 达 服 务 
器 ， 因 此 服务 侨 收 不 到 对 4 号 包 的 确认 ， 不 得 不 选择 重 传 。 这 就 很 奇怪 
了 ， 既 然 3 号 包 可 以 到 达 服 务 器 ， 说 明 不 存在 路 由 交换 或 者 防火 墙 方面 
的 障碍 ， 为 什么 5 号 包 就 到 达 不 了 呢 ? 以 我 过 往 的 经 验 是 无 法 凭空 想象 


出 原因 的 ， 只 能 继续 在 Wireshark 中 寻找 线索 ， 包 分 析 。 先 看 看 图 2 
中 的 3 号 包 ， ne 与 ARP 中 看 
到 的 地 址 一 致 。 


No， Time Source Destination Protocol Info 

1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 
2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at100:15:5d 
3 
| 


0.046875 Client server TCP 51754-389 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACI 


UL 


* 


田 Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 


由 Ethernet II, Src: 00:60:48 Dst :100:15:5d 
由 Internet Protocol Version 4, src: Client (192.168.47.200), Dst: Server (192.168.47.250) 
图 2 


再 看 图 3 中 4 号 包 的 详情 ， 竟 然 是 从 服务 器 的 MAC 地 址 ec:b1:d7 发 出 
来 的 ， 而 不 是 之 前 看 到 的 那个 00:15:5d。 为 什么 会 莫名 其 妙 地 出 现 这 个 
MAC? 它 会 带 来 什么 影响 ? 目前 还 不 得 而 知 。 


No. Time Source Destination Protocol Info 


1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 

2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 

3 0.046875 Client server TCP 51754-389 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SAC 
4 0.046875 Server Client TCP 389-+51754 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 Ms 
| 


Wh 


田 Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: Dst: 00:60:48 
由 Internet Protocol version 4, Src: Server (192.168.47.250), Dst: Client (192.168.47.200) 


图 3 
再 看 图 4 中 的 5 了 包 ， 客户 端 把 它 发 到 这 个 新 的 MAC 地 址 ec:b1:d7 
了 。 难 道 这 束 是 无 法 送 达 的 原因 吗 ? 我 觉得 非常 有 可 能 


No. Time Source Destination Protocol Info 


1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 

2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 

3 0.046875 Client server TCP 51754-389 [SYN] seq=0 Win=65535 Len=0 MSS=1460 SAC 
4 0.046875 Server Client TCP 389-51754 [SYN, ACK] Seq=0 Ack=l Win=8192 Len=0 MS 
5 0.046875 Client server TCP 51754-389 [ACK] Seq=1 Ack=1 Win=139264 Len=0 TSval 


4 | mn 


由 Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 


田 Ethernet II, Src: 00:60:48 Dst: 
由 Internet Protocol Version 4, Src: Client (192.168.47.200), Dst: Server (192.168.47.250) 
图 4 


分 析 到 这 里 ， 我 们 可 以 作出 进一步 推理 。 
服务 器 上 的 一 个 IP 对 应 了 两 个 MAC 地 址 ， 其 中 00:15:5d 能 收 
， 但 不 知道 为 什么 没 发 包 ; 而 ec:b1:d7 能 发 包 却 收 不 到 包 。 我 还 是 第 


一 次 看 到 这 样 诡异 的 状况 。 

2， 客户 端的 表现 也 很 奇怪 。 明 明 能 通过 ARP 获 得 服务 器 的 MAC 地 
址 ( 即 00:15:5d) ,但 一 看 到 对 方 的 发 来 的 包 里 MAC 有 变化 ( 即 变 成 
ec:b1:d7) ， 就 立即 回复 给 这 个 新 MAC。 一 般 的 主机 都 是 持续 使 用 缓存 
在 ARP 表 里 的 那个 老 MAC 地 址 的 。 

也 就 是 说 ， 这 两 台 设备 各 自 有 一 个 奇怪 的 特征 ， 单 独 存在 时 都 不 
会 出 问题 ， 但 是 放 到 一 起 就 不 行 了 。 我 们 只 要 纠正 其 中 一 方 的 行为 ， 
问题 就 能 解决 了 。 

运 维 人 员 最 后 选择 在 客户 端 启 用 ARP 表 ， 果 然 问题 就 消失 了 ， 因 
为 从 此 客户 端 只 发 包 给 00:15:5d。 不 过 我 最 感 兴趣 的 还 是 那 台 服务 器 的 
配置 ， 为 什么 一 个 卫 会 对 应 两 个 MAC 了 呢 ? 后 来 终于 拿 到 了 配置 信息 ， 
原来 服务 器 上 的 多 个 网 卡 被 绑 定 成 一 个 NIC Teaming， 类 型 为 Transmit 
Load Balancing (TLB) 。TLB 的 特点 就 是 收 包 工作 只 由 一 个 网 卡 负 
责 ， 发 包工 作 则 分 摊 给 所 有 网 卡 ， 如 图 5 所 示 。 世 就 是 说 00:15:5d 既 能 
收 也 能 发 ， 但 ecbl:d7 只 能 发 不 能 收 ， 所 以 当 客 户 端 把 包 回 给 ecbl:d7 
的 时 候 就 被 丢弃 了 。 


像 这 样 隐藏 的 问题 ， 假 如 没有 Wireshark 真 不 知道 如 何 解决 。 而 有 
了 Wireshark 却 显得 很 简单 ， 即 使 对 配置 信息 一 无 所 知 也 能 迎刃而解 。 
如 果 说 有 什么 工具 能 彻底 改善 工作 体验 ， 我 的 回答 毫 无 疑问 是 
Wireshark ° 


1998 年 ， 在 波士顿 附近 的 一 座 小 镇 上 ， 几 位 拉 术 人 员 被 召集 到 了 
一 起 。 他 们 都 是 存储 巨头 EMC 的 工程 师 ， 目 的 是 找到 一 个 方法 来 缓解 
当时 网 络 市 宽 所 形成 的 性 能 瓶颈 。 

今天 的 年 轻 人 已 经 难以 想象 20 世 纪 90 年 代 的 网 络 带宽 是 什么 样子 
的 。 初 期 连 数据 中 心里 的 服务 事 都 只 有 十 兆 ， 后 来 才 增加 到 百 兆 。 而 
现在 一 人 台 廉 价 电脑 都 已 经 配 千 兆 卡 了 ， 这 样 对 比 一 下 你 就 能 理解 当时 
的 网 络 有 多 落后 。 低 市 宽 对 个 人 电脑 还 不 算 大 问题 ， 但 对 企业 级 服务 
器 就 是 严重 的 瓶 贷 了 ， 比 如 在 网 络 存储 上 读 写 大 量 数据 的 时 候 (拓扑 
见 图 1) 。 想 象 一 下 ， 假 如 你 是 当时 皮克斯 动画 工作 室 的 员工 ， 每 天 要 
访问 动 辑 1GB 以 上 的 视频 文件 ， 性 能 体验 该 有 多 粳 糕 。 有 什么 办 法 可 
以 解决 这 个 问题 呢 ? 


Ethernet 


以 太 网 交换 机 


服务 器 


图 1 
以 我 的 创新 能 力 和 知识 视野 ， 如 果 参 与 这 个 项 目 估 计 只 能 做 做 流 
控 ， 尺 量 使 传输 性 能 接近 理论 最 大 值 。 而 这 个 项 目 组 显然 更 有 创意 ， 


他 们 想到 了 当时 带宽 已 经 达到 2 Gbit/s 的 FC (Fibre Channel) 。 成 功 的 
话 可 以 从 百 兆 提升 到 2 Gbits， 增 幅 的 确 非常 大 。 

讲 到 这 里 就 得 补充 一 下 网 络 存储 的 架构 。 如 图 2 所 示 .外 ， 当 时 的 网 
络 存 储 是 用 多 个 硬盘 组 成 LUN 《〈“ 即 一 层 虚 拟 的 存储 设备 ) ， 然 后 再 在 
LUN 上 创建 文件 系统 ， 供 以 太 网 上 的 NFS 或 CIFS 客 户 端 访问 。 


Ethernet 


图 2 

可 展 FC 有 别 于 以 太 网 ， 它 文 持 访问 LUN ， 但 不 文 持 访问 文件 系 
统 。 也 就 是 说 ， 我 们 不 能 简单 地 把 图 2 的 以 太 网 连接 替换 成 FC。 如 果 把 
客户 端 和 LUN 之 间 用 FC 连 接 起 来 ， 变 成 图 3 的 样子 ， 那 么 带宽 的 确 能 提 
高 好 多 倍 。 然 而 新 的 问题 又 来 了 ， 客 户 端 是 不 知道 文件 存放 在 LUN 上 
的 位 置 的 ， 所 以 即使 连 上 了 也 不 知道 怎么 读 写 。 这 使 我 们 处 于 一 个 两 
难 的 境地 。 

1. 客户 

2 次 月 


通过 以 太 网 访问 文件 系统 ， 但 生 市 宽 太 小 了 。 
从 FC 访 问 LUN， 却 不 知道 文件 在 LUN 上 的 存放 位 置 。 


LU 人 巴 
NE 
LU 人 巴 
EL 


FF 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 


Ethernet 


Fibre Channel 


图 3 

怎么 办 呢 ? 这 个 项 目 组 想到 了 一 个 办 法 。 他 们 把 以 太 网 和 FC 的 优 
势 结合 起 来 。 先 通过 以 太 网 访问 文件 系统 ， 获 知 文件 存放 在 LUN 上 的 
位 置 ， 然 后 再 通过 FC 去 LUN 上 读 写 。 由 于 文件 位 置 的 数据 量 很 小 ， 所 
以 通过 小 市 宽 的 以 太 网 也 能 快速 完成 ， 而 文件 内 容 的 数据 量 很 大 ，FC 
的 大 市 视 也 能 充分 发 挥 优势 。 根 据 这 个 原理 ， 项 目 组 开发 了 一 个 叫 


FMP (File Mapping Protocol) 的 网 络 协议 ， 专 门 用 于 客户 端 向 文件 系 
统 查 询 文 件 的 存放 位 置 。 图 4 展示 了 增加 FC 连接 后 的 拓扑 ， 即 两 种 网 络 
协作 传输 的 样子 。 


以 太 网 交换 机 


SS 
DN FC 交换 机 


图 4 

访问 文件 当然 不 仅 是 读 写 内 容 这 么 简单 ， 还 要 操作 元 数据 和 避免 
访问 冲突 ， 等 等 。 当 时 CIFS 和 NFS 协 议 在 这 方面 已 经 很 成 熟 了 ， 所 以 
FMP 就 和 它们 结合 起 来 使 用 。 只 有 当 客 户 端 需要 读 写 大 块 的 文件 内 容 
时 才 调 用 FMP， 然 后 再 通过 FC 访问 其 文件 内 容 ， 其 他 时 候 照 样 走 CIFS 
和 NEFS。 举 个 例子 ， 如 果 我 们 看 中 了 文件 系统 里 一 部 10GB 的 电影 ， 那 
就 通过 FMP 获 得 该 电影 文件 在 LUN 上 的 存放 位 置 ， 然 后 再 通过 FC 快速 
地 下 载 它 。 如 果 我 们 只 需要 读 一 个 1KB 的 小 文件 ， 那 直接 通过 CIFS 或 
NFS 就 行 了 ， 因 为 用 了 FC 也 不 见得 能 提高 多 少 性 能 。 换 句 话 说 ， 就 是 
用 FMP 拓 展 了 CIFS 和 NFS， 使 它们 适用 于 高 性 能 场合 。 

至 今 我 的 电脑 中 还 保存 着 一 份 FMP 网 络 包 。 如 图 5 所 示 ，Protocol 
显示 为 FMP， 存 储 服务 器 通过 GetMap Reply 把 文件 内 容 在 LUN 上 的 位 
置 (Extent) 告知 客户 端 。 实 现 起 来 就 这 么 简单 。 


Fikter fmp 加 Expression... Clear Apply Save 


No, Time Source Destination Protocol Info 

27956 331.583083 Client Sserver FMP V3 GetMap Call (Reply In 27958) 
27958 331.583930 server Client FMP V3 GetMap Reply (Call In 27956) 
27959 331.672564 Client server FMP V3 GetMap Call (Reply In 27961) 
27961 331.673070 server Client FMP V3 GetMap Reply (Call In 27959) 
27962 331.686955 Client Sserver FMP V3 GetMap Call (Reply In 27964) 
27964 331.687712 server Client FMP V3 GetMap Reply (Call In 27962) 
4 | 员 


Transmission Control Protocol, src Port: 4656 (4656), Dst Port: 1021 (1021), 
Remote Procedure Call, Type:Reply XID:0x51239349 
File Mapping Protocol 
[Program Version: 3] 
[Procedure: GetMap (8)] 
status: OK (0) 
Message Number: 175 
Cookie: Ox00000000 
File size: 1070735360 
Extent List Length: 5 
日 Extent (1) 
First Logical File Block: 22272 
Number of Blocks: 20 
volume ID inside DART: Ox05b57a04 
start offset: 274892 
Extent State: VALID_DATA (0) 
Extent (2) 
Extent (3) 
Extent (4) 


[+ 


加 此 


田 田 田 


图 5 

FMP 刚 面世 的 时 候 顾 受 欢 迎 ， 因 为 性 能 提升 太 明 显 了 ， 连 中 国 最 
顶尖 的 科研 机 构 和 证 券 公 司 都 在 用 它 ， 我 刚 毕 业 时 还 用 Wireshark 帮 它 
们 分 析 过 几 次 FMP 包 。 用 我 国学 术 界 今年 流行 的 语言 来 说 ， 这 个 技术 
也 算是 “突破 了 汉 : 诺 依 曼 瓶 颈 的 束缚 ， 产 生 了 巨大 的 国际 影响 ”。 后 来 
的 PNFS ( 即 NFSv4.1) 也 借用 了 它 的 理念 ， 图 6 中 的 LAYOUTGET 操 
作 ， 本 质 上 和 图 5 的 GetMap 就 是 异曲同工 。 


Filter: | nfs,.main_opcode == 30 -| Expression... Clear Apply Save 


No. Time Source Destination Protocol Info 
10 6.342130000 Client server NFS v4 call (Reply In 11) LAYOUTGET 
11 6.356517000 server Client NFS v4 Reply (Call In 10) LAYOUTGET 
19 9.195982000 Client server NFS v4 call (Reply In 20) LAYOUTGET 
20 9.210407000 server client NFS v4 Reply (tcall In 19) LAYOUTGET 


请 | 中 


四 Remote Procedure Cal1，Type:Cal1 XxID:0x86249770 
日 Network File System， Ops (3): SEQUENCE, PUTFH, LAYOUTGET 
[Program Version: 4] 
[V4 Procedure: COMPOUND (1)] 
田 Tag: <EMPTY> 
minorversion: 1 
日 Operations {count: 3):; SEQUENCE, PUTFH, LAYOUTGET 
Cpcode: SEQUENCE (53) 
四 Opcode: PUTFH (22) 
田 Opcode: LAYOUTGET (50) 
[Main Gpcode: LAYOUTGET (50)] 


图 6 

可 惜 好 景 不 长 ， 随 着 以 太 网 的 更 新 换代 ， 带 宽 已 经 接近 甚至 超过 
了 FC。 现 在 单 用 NFS 或 CIFS 束 可 以 实现 很 高 的 性 能 ， 依 赖 FMP 的 场景 
也 惑 越 来 越 少 了 ， 过 去 两 年 里 其 至 没有 一 家 公司 找 我 看 过 FMP 或 者 
pNFS 的 包 。 波 士 顿 附近 的 项 目 组 也 早 就 解散， 我 现在 只 能 从 旧 资 料 中 
找到 这 几 位 老 同 事 的 名 字 : Jeff、Boris、Jason、Peter， 还 有 一 位 姓 
Jiang 的 华人 。 在 世界 IT 史上 ， 类 似 命 运 的 优秀 产品 还 有 不 少 ， 美 好 而 
短暂 ， 就 像 屋 花 一 现 。 我 写 这 篇 文章 并 不 只 是 为 了 缅怀 这 个 我 付出 过 
心血 的 协议 ， 也 想 借 它 揭示 开 界 一 个 普遍 规律 一 一 网 络 协议 的 面世 是 
受 市 场 需求 驱使 的 。 我 们 完全 可 以 根据 自己 的 需要 设计 一 个 新 协议 ， 
不 要 以 为 这 是 遥 不 可 及 的 事情 。 不 过 在 这 个 日 新 月 异 的 领域 中 ， 新 的 
协议 可 能 很 快 就 会 老 去 ， 而 老 协 议 却 可 以 焕发 第 二 春 。 唯 一 能 青春 永 
驻 的 ， 只 有 Wireshark 了 。 


我 朋友 最 近 巡 到 了 一 桩 怪事 ， 他 把 服务 器 的 网 络 从 千 兆 改造 成 万 
兆 ， 没 想到 用 户 纷纷 抱怨 性 能 下 降 。 于 是 他 不 得 不 降 回 千 焰 ， 用 户 们 
反而 感觉 性 能 恢复 了 。 朋 友 觉 得 很 委屈 ， 不 明白 是 什么 原因 导致 他 好 
心 办 成 了 坏事 。 

改造 之 后 的 网 络 拓 扑 大 体 如 图 1 所 示 。 交换机 和 服务 右 之 间 从 干 兆 
升 到 万 兆 了 ， 而 客户 端 和 交换 机 之 间 维 持 干 兆 不 变 。 


A 
> - 
客户 端 交换 机 服务 器 
图 1 


我 分 析 了 改造 前 后 的 网 络 包 。 发 现 当 数据 从 客户 端 流向 服务 器 
上 时， 两 者 看 不 出 任何 差别 。 但 是 当 数 据 从 服务 器 流向 客户 端 时 ， 改 造 
后 的 重 传 率 明 显 增加 了 。 我 们 可 以 在 Wireshark 上 点 击 Analyze 菜 单 ， 再 
点 击 Expert Info 看 到 重 传统 计 ， 如 图 2 所 示 。 


和 
顾 Wireshark: 4752 Expert Infos 


Errors: 2 (6) [Warnings: 3 (159) | Notes: 121 (4587) (Chats: 0 (0) | Detaits: 4752 | packet Comments: 0 


Group 4 Protocol 4 Summary 


由 Sequence TCP This frame is a (suspected) fast retransmission 


中 | 由 Sequence TCP This frame is a (suspected) retransmission 


回 Limit to display filter 


图 2 
这 里 要 补充 说 明 一 下 ， 只 要 很 少 的 丢 包 重 传 就 足以 对 性 能 造成 巨 
影响 。 当 局域网 中 的 重 传 率 超过 0.1% 就 值得 采取 措施 了 ， 快 速 重 传 
和 超时 重 传 的 影响 很 不 一 样 ， 所 以 这 个 经 验 值 仅 供 参 考 。 假 如 能 降低 
到 零 当 然 最 好 ， 但 实际 上 0.01% 以 下 的 重 传 率 是 很 难 消除 的 。 


从 Wireshark 看 到 重 传 现象 之 后 ， 接 下 来 的 任务 就 是 找 出 为 什么 高 
带宽 反而 伴随 着 更 多 重 传 了 。 我 的 猜测 是 换 成 万 兆 之 后 ， 服 务 器 的 发 
送 速 度 加 快 了 ， 但 由 于 客户 端 还 是 和 于 兆 的 ， 一 时 消化 不 了 这 么 多 ， 所 
以 数据 束 拥 堵 在 交换 机 上 。 当 交换 机 的 缓冲 区 修 占 满 时 ， 束 不 得 不 把 
包 丢 挥 ， 从 而 导致 尽 体 性 能 反而 不 如 改造 前 。 

网 络 理论 说 起 来 太 抽象 了 ， 所 以 我 们 用 图 3 来 辅助 理解 。 水 龙头 相 
当 于 服务 右 ， 漏 斗 相 当 于 交换机 。 改 造 前 的 水 龙头 流速 和 调 斗 的 出 口 
流速 你 持 一 怪 ， 所 以 虽然 不 快 但 也 不 至 于 洲 出 。 把 水 龙头 改造 变 大 之 
后 ， 其 流速 超过 了 漏斗 出 口 的 流速 ， 因 此 过 了 一 段 时 间 水 束 会 次 出 漏 
斗 。 下 次 你 开车 墙 在 下 高 架 的 下 道上 时 ， 也 可 以 体验 一 下 相同 的 拥塞 
原理 。 


/ \ 
F \ 
/ NA 
\ / NS 
\ 1 N 
\ /1 N 
\ F \ 
| jt \ 
NS / N F 
W / \ / 
| : | | | 


改造 前 改造 后 


图 3 

那 像 我 朋友 一 样 把 万 兆 改 回 和 于 兆 就 是 对 的 吗 ? 其 实 也 不 一 定 ， 假 
如 有 10 个 客户 端 同时 从 服务 右 下 载 数 据 ， 那 在 服务 右上 用 万 兆 网 络 束 
很 合适 ， 因 为 这 些 客户 端 可 以 平 摊 流 量 ， 数 据 束 不 会 拥堵 在 交换 机 


上 。 这 相当 于 在 漏斗 上 再 控 9 个 出 水 口 ， 也 就 不 会 溢出 来 了 。 换 句 话 
说 ， 服 务 器 的 带宽 本 来 就 应 该 比 客户 端 大 才 合 理 ， 尤 其 是 在 客户 端 特 
别 多 的 时 候 。 不 过 为 了 避免 拥塞 ， 最 好 设计 一 种 流 探 机 制 ， 人 允许 交 换 
机 在 过 载 时 通知 服务 器 发 慢 一 点 ， 即 便 暂 停 传 输 的 效果 也 会 比 拥塞 丢 
包 好 。 

IEEE 802.3x 所 定义 的 “暂停 帧 ”(\Pause Frame) 就 实现 了 这 个 功 


mul 
EE 
O 


: 当 交 换 机 的 缓 神 区 即将 被 填 满 时 ， 它 可 以 给 服务 器 发 一 个 暂停 
帧 ， 人 。 这 样 就 避免 了 洪 出 丢 包 ， 从 而 避免 了 重 传 。 
交换 机 在 等 待 时 间 里 会 继续 把 缓冲 区 的 数据 传 给 客户 端 ， 使 负担 得 以 
释放 。 

.服务 器 需要 等 待 的 时 间 长 度 是 由 暂停 帧 指定 的 pause_time 指 定 的 。 

等 待 时 间 之 后 ， 服 务 器 才 可 以 发 数据 。 

.假如 交换 机 缓冲 区 里 的 数据 提前 消化 了 ， 它 还 可 以 给 服务 器 发 一 
个 pause_time 为 0 的 暂停 帧 ， 告 诉 服务 器 无 需 等 待 了 。 

我 的 实验 室 机 器 上 抓 不 到 暂停 帧 ， 因 为 它 太 底层 了 。 好 在 
Wikipedia 上 有 一 个 例子 ， 是 暂停 时 间 为 65535 quanta 的 (每 个 guanta 相 
当 于 512 比 特 时 间 ) ， 如 图 4 所 示 。 有 兴趣 分 析 这 种 包 的 话 ， 也 可 以 到 
Wireshark 官 网 下 载 示 例 包 。 


日 Ethernet II, Src: 42networ_30:41:50 (O00:0TFT:5d:30:41:50), Dst: Spanning-tree-(Tfor-bridges)_ol 
日 Destination: spanning-tree-(for-bridges)_01 (01:80:c2:00:00:;01) 
Address: ei et Cfor-bridges)_01 (C01:80:c2:00:00:01) 
dt g .. = IG bit: Group address (multicast/broadcast) 
He rs i .= LG bit: Globally unique address (factory default) 
日 Source: 42networ ee 41: 50 (00:0f:5d:30:41:507 
Address: 42networ_30:41:50 (00:0f:5d:30:41:50) 
coal Rg .. = IG bit: Individual address (unicast) 
... .= LG bit: Globally unique address (factory default) 
Up MAC CE Cox88083 
Pause: 0Oxoo0o01 


Quanta: 65535 


暂停 帧 的 Destination MAC 地 址 固定 是 01-80-C2-00-00-01， 所 以 在 
不 同 的 环境 中 看 到 相同 的 地 址 也 不 要 觉得 奇怪 。 另 外 ， 和 暂停 帧 可 以 是 
双向 的 ， 即 服务 器 在 必要 的 时 候 也 可 以 向 交换 机 请 求 暂停 。 

在 过 去 几 年 里 ， 我 在 不 少 生产 环 境 中 利用 暂停 帧 解决 过 性 能 问 
题 。 现 在 FCoE (Fibre Channel over Ethernet) 技术 似乎 有 发 展 的 势头 ， 
它 也 需要 依赖 暂停 帧 来 缓解 拥塞 ， 所 以 相信 和 暂停 帧 的 应 用 会 越 来 越 广 
泛 的 。 记 住 要 在 主机 和 交换机 上 都 相应 配 好 ， 否 则 是 不 会 起 效 的 ， 酸 
置 命令 请 参照 厂商 提供 的 手册 。 

从 暂停 帧 的 工作 原理 可 知 ， 它 适用 于 相 邻 设备 间 的 流 控 ， 所 以 在 
图 1 这 样 的 环境 中 可 以 工作 得 很 好 。 但 是 在 图 5 的 环境 中 ， 如 果 你 指望 
它 从 客户 端 一 路 影响 到 服务 器 ， 那 束 不 现实 了 。 只 有 TCP 层 的 流 控 ， 才 
能 立即 作用 于 整个 路 径 。 


客户 端 交换 机 路 由 器 路 由 器 交换 机 服务 器 


图 5 


也 许 我 应 该 去 注册 一 家 公司 ， 专 门 提供 网 络 分 析 服 务 。 目 前 看 来 
生意 应 该 会 不 错 ， 因 为 已 经 有 很 多 人 来 找 我 分 析 网 络 包 了 ， 有 的 居然 
还 主动 要 求 付费 ， 让 我 觉得 技术 员 的 人 生还 是 有 一 点 扩 希 望 的 。 比 如 
最 近 有 个 中 东 公 司 的 远程 镜像 偏 慢 ， 人 研 究 了 很 久 都 没有 进展 ， 因 此 便 
寄 硕 望 于 Wireshark， 抓 了 个 包 给 我 分 析 。 


该 环境 的 网 络 拓扑 如 图 1 所 示 ， 主 数据 中 心 位 于 中 东 ， 需 要 定时 把 


新 数据 同步 到 英国 去 ， 常 


党 因为 传输 太 慢 而 同步 超时 。 


中 东 


我 用 Wireshark 打 开 网 络 包 


英国 


图 1 
， 找 到 Analyze ~ Expert Info 菜 单 选 项 


果然 看 到 了 图 2 所 示 的 大 量 重 传 。 由 于 全 部 网 络 包 也 就 十 多 万 个 ， 这 个 


重 传 比例 已 经 算 相 当 高 了 。 


Group 4 Protocol 
由 Sequence TCP 


Sequence TCP 


4 Summary 


Thisframe is a (suspected) retransmission 


Thisframe is a (suspected) fast retransmission 


| 
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加 Limit to display filter 


图 2 


那 导 致 重 传 的 因素 是 什么 呢 ? 当 我 点 到 Statistics 一 Conversations 羡 


单 选项 时 ， 图 3 的 统计 结果 似乎 给 了 一 些 启示 


这 台 服 务 器 竟然 用 了 


50 个 TCP 连 接 来 做 数据 同步 。 


TCP Conversations 
AddressA 4 PortA 4 AddressB 4 PortB 4 Packets 4 Bytes 4 Packets A—B 4 Bytes A—B 4 Packets A~B 4 Bytes A~B < 
Middle East 47309 Britain 2051 3388 2945 830 2811 670 
Middle East 49989 Britain 2051 3590 3214 316 3081 322 
Middle East 33305 Britain 2051 3679 3183 774 3010150 
Middle East 59533 Britain 2051 3574 3130 584 2994 062 
MiddleEast 41991 Britain 2051 3746 3 302 434 3148 778 
MiddleEast 48475 Britain 2051 3 408 2 998 506 2853 590 
MiddleEast 53170 Britain 2051 3549 3100 630 2913 990 
4 Mh 


Name resolution Limit to display filter 


图 3 

使 用 多 个 TCP 连 接 的 原因 不 难 理解 。 因 为 网 络 延迟 、 拥 塞 和 应 用 层 
设计 等 因素 ， 单 个 连接 无 法 占 满 整个 物理 链 路 。 比 如 用 某 些 协议 传输 
一 连 串 字母 所 命名 的 小 文件 时 ， 在 链 路 上 可 能 形成 图 4 这 样 的 断断续续 


的 数据 流 ， 就 像 用 吸管 喝 饮料 时 混 进 了 大 量 的 空气 。 
一 > 四 一 国 加 四 看 轩 国 和 一 
图 4 
这 个 问题 的 确 是 可 以 通过 增加 一 些 连接 数 占 满 链 路 来 解决 。 图 5 演 


示 了 增加 一 个 连接 后 的 状况 (传输 的 是 一 连 串 数字 命名 的 文件 ) ， 可 
见 相同 时 间 里 传输 的 数据 总 量 增加 了 。 


\. a 
~ mm 


图 5 


那 是 不 是 连接 数 越 多 越 好 呢 ? 从 理论 上 看 并 非 如 此 。 当 连接 数 多 
到 足以 占 满 整个 链 路 时 ， 再 增加 连接 就 没有 意义 了 ， 其 至 可 能 带 来 负 
面 效 果 。 这 是 由 以 下 原因 造成 的 。 

.多 个 连接 需要 更 高 的 资源 成 本 。 比 如 连接 的 建立 和 上 断 开 ， 以 及 维 
护 每 个 连接 需要 分 配 的 内 存 ， 都 会 消耗 服务 器 的 资源 。 

: 太 多 连接 抢占 同一 个 链 路 ， 有 可 能 会 增加 丢 包 率 。 束 像 用 多 辆 车 
来 运输 货物 可 以 加 快速 度 一 样 ， 当 车 辆 多 到 足以 引发 交通 事故 时 就 适 
得 其 反 了 。 说 不 定 图 2 中 的 丢 包 就 有 一 部 分 是 过 多 的 连接 数 导 致 的 。 

以 上 只 是 理论 分 析 ， 我 决定 在 实验 室 中 粗略 模拟 一 下 。 该 实验 环 
境 中 的 最 大 发 送 窗口 是 65535 字 节 ， 当 我 只 启用 一 个 TCP 连 接 时 ,“ 中 
东 ” 很 快 就 发 送 了 65535 字 节 的 “在 途 字 节 数 ”"， 即 耗 光 了 发 送 窗口 ， 因 此 
Wireshark 提示 |TCP window Fulj 《〈 见 图 6) 。 这 种 情况 下 “中 东 ” 只 
好 停 下 来 等 待 “英国 * 的 Ack， 收 到 Ack 后 才能 接着 往 下 传 。 这 也 说 明了 
带宽 没有 被 完全 利用 ， 应 该 增加 发 送 窗 口 或 者 连接 数 来 补充 。 当 我 把 
连接 数 增加 到 3 个 时 ， 果 然 就 不 再 看 到 这 个 提示 了 。 


No. Time Source Destination Protocol Info 


71 0.392805000 Middle East Britain TCP [TCP Window Fu11] 64560-12345 [ACK] Seq=202344 Ack=1 
72 0.395142000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=142521 Win=65535 Len=0 
73 0.395219000 Middle East Britain TCP [TCP window Fu11] 64560-12345 [ACK] Seq=205200 Ack=1 
74 0.397470000 Britain Middle East TCP 12345-64560_[ACK] Seq=1 Ack=145377 Win=65535 Len=0 
75 0.397549000 Middle East Britain TCP 64560-12345 [ACK] Seq=208056 Ack=1 
76 0.400139000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=148233 Win=65535 Len=0 
77 0.400218000 Middle East Britain TCP [TCP Window Fu11] 64560-12345 [ACK] Seq=210912 Ack=1 


78 0.402431000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=151089 Win=65535 Len=0 
pe se me i ws PP ey i 


9 Checksum: 0xa4dc [validation disabled] 
Urgent pointer: 0 
3 [SEQ/ACK analysis] 
[iRTT: 0.040996000 seconds] 


图 6 

注意 : Wireshark 提 示 的 [TCP window Fulj 和 [TCP zerowindow] 意义 不 同 ， 但 是 有 逢 

多 人 会 混淆 。 前 者 表示 这 个 包 的 发 送 方 意识 到 “在 途 字 节 数 ”已 经 达到 对 方 所 声明 的 接收 窗口 ， 

不 能 再 发 了 ; 而 后 者 表示 这 个 包 的 发 送 方 意识 到 自己 的 缓存 区 已 经 满 了 ， 无 法 接收 更 多 数据 。 
局 用 3 个 TCP 连 接 时 的 性 能 如 图 7 所 示 ， 为 5.055 Mbits， 跟 理想 速 

度 很 接近 (该 公司 租用 的 带宽 确实 小 了 点 ) ， 此 时 在 包 里 也 没有 看 到 


Display filter: none 
Ignored packets: 0 (0.00059) 


Traffic 4 Captured 4 Displayed 4 Displayed % 4 Marked 4 Marked % 4 
Packets 2534 2534 100.0003% 0 0.000% 
Between first and last packet 7.904 sec 

Avg. packets/sec 320.604 

Avg. packet size 1971 bytes 

Bytes 4994424 4994424 100.00036 

Avg. bytes/sec 631899.786 

Avg. MBit/sec 5.055 


而 当 连 接 数 增加 到 50 个 时 ， 残 降 到 了 图 8 所 示 的 4.081 Mbit/s 了 ， 
不 多 20% 的 幅度 ， 同 时 也 出 现 不 少 重 传 ( 重 传 图 就 不 贴 出 来 了 ) 。 可 
实验 结果 和 我 们 的 理论 分 析 一 致 。 


己 陛 


Display 
Display filter: none 
lgnored packets: 0 (0.000%) 


Traffic 4 Captured 4 Displayed 4 Displayed % 4 Marked 4 Marked % 1 
Packets 13623 13623 100,000% 0 0.000% 
Between first and last packet 34,.745 sec 


Avg. packets/sec 392.088 

Avg. packet size 1301 bytes 

Bytes 17722364 17722364 100,000% 
Avg. bytes/sec 510073.000 

Avg. MBit/sec 4.081 


图 8 

以 上 分 析 ， 从 理论 到 实验 都 说 明了 连接 数 并 非 越 多 越 好 。 那 究 疯 
多 少 是 最 合适 的 呢 ? 这 和 网 络 带 辆 、 往 返 时 间 以 及 发 送 窗口 都 有 天 
系 。 我 没有 固定 的 计算 公式 ， 只 能 一 边 调 方 连 接 数 一 边 观 测 ， 测 到 最 
佳 性 能 时 的 那个 连接 数 就 是 了 。 本 文 开头 提 到 的 那个 “中 东 - 英 国 ” 镜 像 
问题 ， 后 来 也 是 这 样 调 优 的 。 不 过 这 种 调 优 一 般 提 升幅 度 有 限 ， 对 于 
很 多 中 东 土 察 公 司 来 说 ， 最 直截了当 的 方式 还 是 购买 带宽 和 加 速 器 。 

看 到 这 里 ， 你 可 能 会 想起 在 中 国 很 流行 的 多 线程 下 载 工具 ， 其 原 
理 是 否 也 是 通过 提高 链 路 利用 率 来 提升 速度 呢 ? 比如 家 里 装 了 百 兆 宽 
之， 用 单线 程 下 载 电 影 的 时 候 只 有 100KB/s， 用 了 双 线 程 束 能 接近 
200KB/s 了 。 这 个 原理 其 实 和 本 文 所 分 析 的 很 不 一 样 ， 因 为 它 的 性 能 瓶 
贷 并 不 在 链 路 或 者 网 络 协议 上 ， 而 是 服务 句 给 每 个 连接 所 设置 的 速度 
限额 。 要 是 在 服务 强 上 解除 了 限额 ， 那 很 可 能 单线 程 的 性 能 也 可 以 超 
过 200KB/s 。 


作为 理性 程度 排行 第 二 的 天 蝎 座 男生 ， 我 当然 不 相信 星座 学 说 ， 
更 无 法 理解 处 女 座 们 为 什么 宣称 自己 有 强迫 症 。 其 实 即使 是 轻 度 的 强 
迫 症 都 非常 痛苦 ， 经 常 遭 受到 各 种 细节 的 折磨 ， 尤 其 是 我 这 种 连 技术 
领域 都 逃 不 过 的 患者 。 举 个 位 单 的 例子 ， 十 多 年 前 我 第 一 次 编辑 网 络 
共 至 文件 时 就 很 焦虑 ， 担 心 其 他 人 也 同时 在 编辑 该 文件 ， 保 存 时 会 发 
生 冲 突 。 这 种 担忧 挥 之 不 去 ， 以 至 于 每 次 都 要 把 共享 文件 移 到 本 地 硬 
盘 ， 等 编辑 好 了 青 移 回 去 。 

人 们 处 理 焦虑 的 方式 各 有 不 同 ， 有 些 人 喝 喝 咖啡 晒 果 太阳 束 觉 得 
风月 静 好 了 。 可 惜 我 束 做 不 到 这 一 感 ， 一 定 要 把 细 市 部 理 清楚 才能 治 


愈 ， 多 年 下 来 竟然 也 “被 迫 * 学 了 不 少 知识 。 比 如 前 面 提 到 的 共享 文件 
的 保存 ， 如 采用 Wireshark 探 究 一 下 ， 会 发 现 满 满 都 是 技术 含量 ， 设 计 
民 好 的 软件 能 完全 避免 我 所 担心 的 意外 。 如 果 你 需要 开发 一 个 处 理 文 
件 的 软件 ， 也 可 以 参 (shin) 考 〈zhai) 这 些 设计 。 本 文 就 通过 几 个 简 
单 的 实验 ， 分 析 一 下 Notepad、Notepad++ 和 Microsoft Excel 在 保存 文件 
时 的 不 同 表现 。 

Notepad 实 给 

1. 让 小 明和 小 红 分 别 在 自己 的 电脑 上 用 Notepad 打 开 同 一 个 共享 
文件 \10.32.106.84\nas_share\Home\test\abc.txt 。 

2. 小 明 写 上 一 句 “ 我 是 小 明 ” 并 保存 ， 然 后 小 红 写 上 一 句 “ 我 是 小 
红 ” 并 保存 。 

3. 两 人 都 关 掉 文件 之 后 再 打开 ， 发 现 只 有 小 红 写 的 那 句 话 保存 下 
来 了 。 

从 实验 结果 可 见 ，Notepad 完 全 没有 保 扩 机 制 ， 所 以 虽然 两 个 人 都 
保存 成 功 ， 但 小 明 保存 的 内 容 被 小 红 保存 的 覆盖 了 。 这 种 事情 遇 到 一 
次 就 会 给 强迫 症 患者 留 下 一 者 子 的 阴影 。 

Notepad++ 实 验 

1. 让 小 明和 小 红 分 别 在 自己 的 电脑 上 用 Notepad++ 打 开 同 一 个 共 
享 文件 \10.32.106.84\nas_share\Home\test\abc.txt ° 

2. 小 明 写 上 一 句 “ 我 是 小 明 *” 并 保存 ， 这 时 候 小 红 的 NotePad++ 弹 
出 图 1 所 示 的 提示 。 


@ 10.32,106.84\nas_share\Home\test\abc.txt 


Thrs file has been modified by another program,. 
Do you want to reload it? 


图 1 

3. 小 红 点 击 Yes 加 载 了 小 明 编 辑 过 的 内 容 ， 再 写 上 一 句 “ 我 是 小 红 ” 
并 保存 。 

4. 两 人 都 关 掉 文件 之 后 再 打开 ， 发 现 两 句 话 都 被 保存 下 来 了 。 

从 实验 结 末 可 见 ，Notepad++ 有 不 错 的 保护 机 制 ， 所 以 不 会 导致 数 
据 丢 失 。 那 它 是 怎样 实现 这 个 机 制 的 呢 ? 用 Wireshark 看 看 束 知 道 了 。 
我 在 小 红 的 电脑 上 启动 抓 包 ， 发 现 当 小 明 点 击 保存 时 ， 文 件 服务 器 给 
小 红 的 电脑 发 了 一 个 Notify Response ， 即 通知 她 文件 abc.txt 被 改动 了 

( 见 图 2 右 下 角 ) 。Notepad++ 收 到 这 个 Notify 之 后 ， 就 可 以 提示 小 红 重 
新 加 载 文 件 内 容 了 。 原 理 就 是 这 么 简单 。 


No. Time Source Destination Protocol Info 

1 0.000000000 File_server Xiaohong SMB2 Notify Response 
2 0.000618000 xiaohong File_server SMB2 Notify Request 
| 


NetBIOS Session service 

日 SMB2 (Server Message Block Protocol version 2) 
因 SMB2 Header 

日 Notify Response (OxOf) 


0000 44 39 c4 50 a9 f6 ec 30 91 e3 a6 80 08 00 45 00 
0010 00 8e e3 0a 00 00 3a 06 56 b4 0a 20 6a 54 0a 20 
pA md: 01 bd e8 43 41 6c 60 27 bd 13 bl 32 20 18 
0030 TE 00 00 00 62 Te 33 4d 42 40 00 

00 00 00 00 00 00 of 00 00 00 03 00 00 00 00 00 
0050 00 00 if 04 00 00 00 00 00 00 3b 00 00 00 03 00 
0060 00 80 01 00 00 00 0a 02 00 00 00 00 00 00 00 00 
0070 00 00 00 00 00 00 00 00 00 00 09 00 48 00 la 00 
0080 00 00 00 00 00 00 03 00 00 00 0e 00 00 00 61 00 
0090 62 00 63 00 2e 00 74 00 78 00 74 00 


图 2 

Excel 实 难 

1. 让 小 明 在 目 己 的 电脑 上 用 Excel 打 开 共 享 文 件 
\10.32.106.84\nas_share\Home\test\test.xlsx 并 编辑 。 

2. 让 小 红 也 打开 同一 个 文件 ， 结 果 收 到 了 图 3 所 示 的 提示 ， 说 明 


test, xlsx is locked for editing 


by xiaoming ， 


Dpen Read-Only’ or 十 中 'Notify’ to open read-only and receive notification 
when the document is no langer in Use， 


图 3 

由 实验 结果 可 见 ，Excel 的 保护 机 制 更 加 严密 且 贴 心 ， 连 谁 在 编辑 
该 文件 都 提示 出 来 了 。 因 此 小 红 可 以 根据 提示 找到 小 明 ， 让 他 赶紧 编 
辑 好 然后 关 掉 。 那 么 问题 来 了 ，Excel 是 怎样 做 到 这 一 切 的 呢 ? 我 在 小 
红 的 电脑 上 抓 了 个 包 ( 见 图 4) ， 发 现 她 在 打开 test,xlsx 时 ， 会 党 试 创建 
一 个 叫 一 $test.xlsx 的 临时 文件 。 而 因为 该 文件 已 经 被 其 他 人 创建 并 锁 


定 ， 所 以 小 红 收 到 了 “STATUS_SHARING_VIOLATION” 的 报错 。 接 着 
小 红 读 出 一 $test.xlsx 的 内 容 ， 得 到 了 锁定 者 的 名 字 〈 见 图 4 右 下 角 的 


xiaoming) 9 


No., Time Source Destination Protocol Info 
121 0. 543945000 Xxiaohong File_server SMB2 Create Request File: Home\test\~$test.xlsx 
122 0. 544708000 File_server Xxiaohong SMB2 Create Response, Error: STATUS_PENDING 
123 0.545529000 File_server Xxiaohong SMB2 Create Response, Error: [STATUS_SHARING VIOLATION 
125 0.546684000 xiaohong File_server SMB2 Create Request File: 
126 0. 547681000 File_server Xxiaohong SMB2 Create Response File: 
127 0.547922000 xiaohong File_server SMB2 Close Request File: 
128 0. 548450000 File_server Xxiaohong SMB2 Close Response 
129 0. 549457000 xiaohong File_server SMB2 Create Request File: Home 
130 0.550251000 File_server xiaohong SMB2 Create Response File: Home 
131 0.551476000 xiaohong File_server SMB2 Close Request File: Home 
132 0.551716000 Xiaohong File_server SMB2 Create Request File: Home\test\~$test.xlsx 
133 0.552214000 File_server xiaohong SMB2 Close Response 
134 0.552413000 xiaohong File_server SMB2 Create Request File: Home\test 
135 0.552443000 File_server xiaohong SMB2 Create Response, Error: STATUS_PENDING 
136 0.553227000 File_server Xxiaohong SMB2 Create Response File: 
138 0. 553292000 File_server xiaohong SMB2 Create Response File: Home\test 
139 0.553447000 xiaohong File_server SMB2 Read Request Len:165 off:0 File: 
140 0.553467000 xiaohong File_server SMB2 Close Request File: Home\test 
142 0.554411000 File_server Xxiaohong SMB2 Read Response 
4 | UN 
00c0 20 08 00 78 00 69 00 61 00 6f 00 6d 00 69 00 6e 
00d0 00 67 00 20 00 20 00 20 00 20 00 20 00 20 00 20 
一 AN nm mm HN mn mn 下 人 AN NA mm AR Am HN Am HN 


图 4 
我 在 小 明 的 电脑 上 也 抓 了 包 。 从 图 5 可 见 的确 是 他 创建 了 一 
$test.xlsx 并 在 里 面 写 上 了 自己 的 名 字 。 


No. Time Source Destination Protocol Info 

239 5.995377000 Xiaoming File_server SMB2 write Request Len:165 off:0 File: Home\test\~$test.xlsx 
240 5.995938000 File_server Xiaoming DCERPC Response: call_id: 2, Fragment: single, Ctx: 0 

241 5.995997000 File_server Xiaoming SMB2 Write Response 


4 加 | 


00b0 69 6e 67 20 20 20 20 20 20 20 20 20 20 20 20 20 ing 
00c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 
00d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 
00e0 20 08 00 78 00 69 00 61 00 6f 00 6d 00 69 00 6e 
00f0 00 67 00 20 00 20 00 20 00 20 00 20 00 20 00 20 
0100 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 


图 5 

分 析 到 这 里 ， 我 们 就 知道 了 Excel 是 怎样 防止 共享 文件 被 意外 覆盖 
的 ， 因 此 编辑 时 再 也 不 用 焦虑 了 “。 我 们 还 可 以 根据 这 个 机 制 设 计 一 些 
办 公 室 恶作剧 。 比 如 议 ， Te 
大 老板 的 名 字 ( 见 图 6 底部 ) ， 这 样 其 他 人 打开 该 文件 时 就 会 以 为 是 大 
老板 正在 编辑 了 ， 只 好 干 等 着 。 


[Geneat | General options for working with Excel, 


Formulas 


Proofin g User Interface options 


Save Show Mini Toolbar on selection GO) 
Enable Live Preview GO) 


Language 
Color scheme: silver| ~ | 


Adyv. d 
ScreenTip style: | Show feature descriptions in ScreenTips 图 


Customize Ribbon 
When creating new workbooks 


Quick Access Toolbar 


Use this font: Body Font [=| 


Add-Ins 
Font size: 11 


Trust Center Default view for new sheets: | Normal View 四 


Include this many sheets: 3 伟 


Personalize your copy of Microsoft Office 


User name: |Big Boss 


本 文 只 是 Wireshark 在 反 疝 工程 上 的 简单 应 用 。 如 果 你 对 这 方面 很 
感 兴趣 ， 完 全 可 以 用 它 来 研究 其 他 软件 ， 有 些 真 的 可 以 调查 到 很 深入 
的 程度 。 


技术 与 工龄 


前 几 天 被 卷 入 了 一 场 辩论 ， 起 因 是 有 人 说 四 十 安 还 在 写 代 码 便 是 
人 生 输 家 。 我 当然 是 站 在 反方 的 ， 这 年 头 坐 在 电脑 面前 就 可 以 建设 社 
会 ， 既 有 成 就 感 还 能 养家 糊口 的 职业 有 多 少 ? 3W 咖 啡 馆 里 那么 多 怀揣 
idea 的 创业 青年 ， 都 只 差 一 个 程序 员 束 可 以 改变 世界 了 ， 还 不 够 你 目 罕 


的 吗 ? 不 过 反方 提出 的 一 些 论据 也 很 不 科学 ， 比 如 吹 噬 上 自己 号 边 的 老 
工程 师 有 多 牛 多 牛 ， 好 像 工龄 长 了 都 能 修炼 成 仙 一 样 。 这 一 点 我 在 刚 
续 业 时 吏 很 不 以 为 然 ， 今 天 束 借 一 个 Wireshark 案 例 表 达 一 下 我 的 看 
法 。 

这 是 我 刚 参 加 工作 不 久 的 事情 。 当 时 我 还 在 休假 ， 老 板 的 电话 驶 
妃 杀 过 来 了 ， 说 是 有 位 大 客户 发 大 ， 发 来 一 封 措辞 极其 疡 万 的 邮件 ， 
导致 我 司 没 有 工程 师 敢 再 跟 他 对 话 了 。 由 于 该 邮件 中 贴 了 很 多 
Wireshark 般 图， 所 以 老板 觉得 由 我 来 回应 好 一 些 。 

虽然 有 被 迫 出 台 的 感觉 ， 但 我 还 是 仔细 读 了 那 封 邮件 。 原 来 事情 
是 这 样 的 : 这 位 客户 买 了 我 司 最 高 端的 服务 器 ， 可 是 上 线 后 发 现 性 能 
不 太 好 ， 于 是 束 投 诉 了 。 我 司 鸭 技术 文 持 认为 瓶颈 是 在 网 络 上 ， 与 服 
务 器 无 和 天 。 客 户 邮 之 大 把 ， 说 目 己 已 经 分 析 过 网 络 包 ， 发 现 是 服务 器 
的 缓存 太 小 导致 的 ， 因 为 TCP 接 收 窗口 最 大 只 有 16KB (如 图 1 方 框 所 


示 ) 。 

No. Time Source Destination Protocol Info 

112 0.001260000 Client Server TCP [TCP segment of a reassembled PDU] 
113 0.001261000 Client Server TCP [TCP segment of a reassembled PDU] 


114 0.001450000 Server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105065333 Win=16384 
115 0.001450000 Server Client TCF 445-63225 [ACK] Seq=4244945014 Ack=105068253 Win=16384 
看 阳 
9 Frame 114: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 
9 Ethernet II，Src: Cisco_e3:a6:80 (ec:30:91:e3:a6:80), Dst: Universa_50:a9:f6 (44:39:c4:50:a9:f 
由 Internet Protocol Version 4, Src: Server (10.32.106.84), Dst: Client (10. 32.200.23) 
3 Transmission Control Protocol, src Port: 445 (445), Dst Port: 63225 (63225), Seq: 4244945014 ， 
Source Port: 445 (445) 
Destination Port: 63225 (63225) 
[stream index: 0] 
[TCP segment Len: 0] 
sequence number: 4244945014 
Acknowledgment number: 105065333 
Header Length: 20 bytes 
四 .... 0000 0001 0000 = Flags: Ox010 (ACK) 
[Calculated window size: 16384] 


Window size scaling factor: -1 (unknown)] 


图 1 

这 个 截图 果然 把 技术 支持 镇 住 了 ， 因 为 Wireshark 是 不 会 骗 人 的 ， 
16KB 的 确 是 太 小 了 啊 。 它 意味 着 客户 端 每 发 16KB 的 数据 就 不 得 不 停 下 
来 等 待 服务 器 的 Ack， 我 一 台 廉 价 笔记 本 的 接收 窗口 都 不 只 64KB 呢 。 


更 糟糕 的 是 ， 这 位 在 签名 档 中 特意 注 明 了 “首席 工程 师 ” 的 客户 很 不 配 
合 ， 嫌 技术 文 持 的 资历 太 浅 。 整 封 邮 件 用 词 之 傲 妖 ， 语 气 之 目 信 ， 让 
我 等 新 毕业 生 户 而 生 其 。 说 实话 ， 我 之 前 见 过 的 活 人 中 ， 只 有 理发 师 
征 有 首席 头衔 的 。 幸 好 本 人 脸 皮 够 犀 ， 而 且 擅长 在 复杂 的 纠纷 中 过 滤 


出 纯 技术 部 分 。 
“从 Wireshark 可 见 服 务 器 的 TCP 接 收 窗口 的 确 很 小 ， 这 也 是 客户 的 
论据 。 


:接收 窗口 太 小 肯定 会 影响 网 络 性 能 。 

当前 网 络 性 能 的 确 是 很 差 。 

这 个 推理 过 程 看 起 来 没有 问题 ， 我 只 能 从 最 初始 的 论据 着 手 人 研究 
了 一 一 服务 器 的 接收 窗口 真 的 很 小 吗 ? 仔细 分 析 之 后 ， 我 发 现 还 真 不 
一 定 。 请 看 图 1 底部 的 Wireshark 提示 : “window size scaling 
factor: -1(unknown)”， 我 当时 也 不 慌 是 什么 意思 ， 只 是 觉得 有 必要 搞 
清楚 ， 查 了 很 多 文档 后 才 知 道里 头 大 有 文章 。 

在 TCP 协 议 刚 被 发 明 的 时 代 ， 全 世界 的 带宽 都 很 小 ， 因 此 不 能 一 口 
气 癌 网 络 中 发 送 大 量 数据 。 基 于 这 个 原因 ，TCP 头 中 只 给 接收 窗口 预 留 
了 16 个 比特 ， 这 就 意味 着 它 最 大 只 能 表示 2 -1=65535 字 节 。 随 着 硬件 
的 革命 性 进步 ， 网 络 带宽 越 来 越 大 ，65535 字 下 已 经 不 够 用 了 。 那 有 什 
么 办 法 可 以 扩展 接收 窗口 呢 ? TCP 头 里 是 肯定 没有 多 余 的 空间 了 ， 所 以 
RFC 1323 提 供 了 一 个 有 创意 的 方案 ， 就 是 在 三 次 握手 时 双方 都 把 一 个 
叫 “Window Scale” 的 值 告 知 对 方 。 对 方 收 到 后 会 把 这 个 值 当 作 2 的 指 
数 ， 算 出 来 的 值 再 作为 接收 窗口 的 系数 。 有 了 这 个 系数 就 可 以 把 接收 
窗口 扩展 好 多 倍 了 。 

理论 说 起 来 有 点 复杂 ， 我 们 举 个 实际 的 例子 ， 图 2 是 三 次 握手 的 过 
程 ， 服 务 器 在 2 号 包 中 声明 它 的 Window Scale 为 3， 于 是 客户 端 收 到 后 就 
把 3 作为 2 的 指数 ， 算 得 23 等 于 8。 在 此 后 的 传输 过 程 中 ， 客 户 端 收 到 服 
务 句 所 声明 的 接收 窗口 就 会 自动 乘 以 8。 比 如 在 接 下 来 的 3569 号 包 中 


( 见 图 3) ， 服 务 器 声明 其 接收 窗口 为 16384， 那 客户 端 就 知道 其 真实 
的 接收 窗口 应 该 是 16384x8=131072， 从 而 突破 了 65535 的 限制 。 
Wireshark 也 是 根据 三 里 看 到 的 Window Scale 值 帮 有 我 们 计算 的 ， 
然后 在 括号 中 提示 出 来 (注意 ， 当 你 在 Wireshark 里 看 到 一 个 括号 ， 那 
往往 意味 着 其 内 容 是 附加 提示 ， 而 不 是 网 络 包 本 身 的 内 容 ) 。 


No, Time Source Destination Protocol Info 
1 0.000000000 Client server TCP 63225-445 [SYN] Seq=104758059 Win=8192 Len=0 MSS=1460 
2 0.000791000 Server Client TCP 445-63225 [SYN, ACK] Seq=4243639809 Ack=104758060 Win: 
3 0.000840000 Client Server TCP 63225=445 [ACK] Seq=104758060 Ack=4243639810 Win=6553¢ 


Ud 


日 OpEions: (liZ Dytes), MaximMum segment Size, NO-Operation (NOP), NO-Operation (NOP), SACK perm 
习 Maximum segment size: 1460 bytes 
习 No-Operation (NOP) 
田 No-Operation (NOP) 
加 TCP SACK Permitted Option: True 
习 No-Operation (NOP 


田 Window scale: 3 (multiply by 8) 


图 2 
No, Time Source Destination Protocol Info 
3567 16.396874000 Client server TCP [TCP segment of a reassembled PDU] 
3568 16.396875000 Client server TCP [TCP segment of a reassembled PDU] 


3569 16.397462000 server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105041973 
3570 16.397463000 Server Client TeP 445-63225 [ACK] Seq=4244945014 Ack=105044893 
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AcKnowiedgment number: 1I05041973 
Header Length: 20 bytes 
田 ...。. 0000 0001 0000 = Flags: 0x010 (ACK) 


图 3 

于 是 问题 来 了 了， 如 果 在 三 次 握手 之 后 才 开 始 抓 包 会 怎么 样 ? 不 难 
想象 ， 因 为 Wireshark 无 从 知晓 Window Scale 的 值 ， 所 以 就 无 法 计算 出 
系数 ， 只 好 显示 出 没有 系数 时 的 大 小 ， 图 1 中 的 “window size scaling 
factor: -1(unknown)” 正 好 提示 了 这 种 情况 。 这 也 说 明 图 1 显示 的 
“window size value: 16384” 是 因为 Wireshark 只 看 到 了 这 个 值 ， 但 不 意 
味 着 真实 的 接收 窗口 就 是 16384 字 方 。 客 户 听 了 这 些 分 析 后 悦 然 大 悟 ， 
完全 忘记 我 是 刚 毕 业 的 ， 很 配合 地 去 查 他 的 网 路 瓶 贷 了 人， 最 后 果然 发 
现 问 题 根 源 和 服务 器 无 天 。 可 见 只 要 技术 人 研究 得 足 够 深入 ， 资 历 都 可 
以 当 作 浮云 。 


现在 的 我 已 经 不 会 因为 工龄 受到 歧视 了 ， 有 些 客 户 甚至 要 叫 我 叔 
叔 ， 但 类 似 遭 遇 还 是 会 发 生 在 年 轻 的 同事 号 上 。 这 也 不 是 中 国 特有 的 
问题 ， 似 乎 东方 文化 部 特 别 重 视 工龄 。 有 一 次 请 日 本 同事 吃饭 ， 才 知 
道 他 们 出 电梯 时 竟然 要 以 “ 社 龄 ”为 顺序 ， 由 入 职 早 的 “前 辈 " 走 在 前 面 。 
幸好 我 也 算 老 人 了 ， 人 否则 束 显 得 很 不 礼 狐 。 

也 许 这 也 算是 对 经 验 的 一 种 尊重 吧 ， 但 我 觉得 没 必 要 重视 成 这 
样 ， 更 不 应 该 歧视 新 人 。 工 龄 的 确 可 以 球 积 经 验 ， 但 不 一 定 能 提高 多 
少 拉 能 ， 束 像 你 花 足 够 多 的 时 间 也 可 以 把 相对 论 痛 诵 下 来 ， 但 物理 水 
平 不 会 因此 提高 多 少 。 我 见 到 过 最 殊 殊 业 业 的 老 工程 师 ， 简 直 就 古 一 
个 活体 知识 库 ， 遇 到 很 多 问题 都 能 在 笔记 本 中 翻 出 解决 方案 来 。 可 坪 
遇 到 新 问题 他 就 解决 不 了 ， 因 为 没有 深入 钻研 问题 的 习惯 ， 对 工具 
(比如 Wireshark) 也 不 感 兴趣 。 假 如 这 位 工程 师 和 一 个 喜欢 动脑 筋 的 
应 届 生 应 聘 同 一 职位 ， 我 会 轧 不 犹豫 地 选择 应 届 生 ， 因 为 专业 知识 容 
易 补 ， 钻 人 研 精神 却 很 难 养 成 ， 很 可 能 一 年 后 两 个 人 的 水 平 就 差不多 ， 
再 过 一 年 聘 被 反超 了 。 何 况 工龄 长 的 人 也 不 一 定 束 经 验 丰 语 。 在 一 个 
职位 末了 很 多 年 的 人 ， 有 可 能 是 因为 爱 风 敬业 ， 也 可 能 是 因为 实在 太 
弱 了 ， 一 直 想 跳槽 却 没 成 功 (我 又 暴露 刻薄 的 本 性 了 ) 。 


如 何 科学 地 推 和 责 任 


作为 一 名 高 尚 的 工程 师 ， 我 们 当然 要 勇于 承担 责任 ， 这 几乎 是 业 
内 第 一 美德 。 不 过 只 需 承 担 自己 的 那 部 分 就 够 了 ， 不 要 把 别人 的 也 打 
到 号 上 ， 证 真正 的 责任 方 来 承担 才 最 科学 。 

然而 划分 责任 并 不 容易 。 现 在 一 套 开 系统 往往 涉及 多 个 厂商 的 产 
品 ， 比 如 Oracle 的 数据 库 装 在 了 EMC 的 存储 上 ， 然 后 用 Cisco 的 网 络 设 
备 来 做 远程 镜像 。 项 目 签收 时 各 家 销售 都 很 开心 ， 但 等 到 出 问题 时 就 


轮 到 售后 头疼 了 “。 比 如 数据 库 的 远程 镜像 老 是 同步 不 了 ， 底 层 原因 又 
不 是 一 眼 就 能 看 出 来 的 ， 这 种 情况 应 该 由 谁 来 负责 呢 ? 假设 故障 点 是 
在 网 络 上 ， 那 让 Oracle 的 工程 师 来 排查 反而 耽误 时 间 了 ， 难 不 成 每 次 事 
故 都 要 组 织 大 会 诊 吗 ? 还 好 有 了 Wireshark， 划 分 责任 就 简单 多 了 ， 只 
要 抓 包 分 析 束 行 。 本 文 分 享 的 便 是 这 样 一 个 案例 。 

我 司 做 容 灾 产 品 的 售后 部 门 最 近 接 到 一 个 投诉 ， 说 远程 镜像 死活 
建 不 起 来 。 技 术 文 持 工 程 师 非 常 尽职 ， 仔 细 地 检查 了 所 有 配置 ， 发 现 
都 是 对 的 ; 又 测试 了 网 络 连 搁 ， 也 都 ping 得 通 一 一 总 之 看 上 去 似乎 什么 
都 是 好 的 ， 但 束 是 建 不 起 来 。 一 般 远 程 镜 像 的 网 络 环境 不 会 很 复杂 ， 
忠 古 通过 层 层 路 由 ， 把 数据 从 生产 服务 紫 复 制 到 灾 备 服务 紫 上 上， 如 图 1 


所 示 。 


路 由 器 灾 备 服务 器 


图 1 
怎么 办 呢 ? 你 可 能 会 觉得 凡是 林 沛 满分 享 的 案例 都 是 先 抓 个 包 ， 
然后 英明 神武 地 用 Wireshark 解 决 掉 了 (希望 没有 给 各 位 留 下 这 样 自 吹 


自 擂 的 印象 ) 。 不 过 这 次 却 有 点 狼 狐 ， 我 的 确 在 生产 服务 器 上 抓 了 
包 ， 但 是 并 没有 看 出 原因 。 和 截图 见 图 2， 生 产 环境 (Prod_Server) 的 部 
分 数据 包 发 到 灾 备 服务 器 (DR_Server) 之 后 ， 收 到 了 大 量 的 RST ( 即 
RESET) 回复 ， 说 明 被 拒绝 了 。 


No, Time Source Destination Protocol Info 
24 3.042969 Prod_server DR_Sserver TCP 54395-8888 [ACK] Seq=46613 Ack=291 Win=139 
25 3.042969 DR_Sserver Prod_server TCP 8888-54395 seq=291 Ack=32133 Win=209 


26 3.042969 Prod_server DR_Server TCP 54395~8888 Seq=55301 Ack=291 Win=139 
27 3.042969 “DR_Sserver Prod_server TCP 8888-54395 Seq=291 Ack=36477 Win=209 
28 3.042969 Prod_server DR_Server TCP 54395~8888 Seq=63989 Ack=291 Win=139 


29 3.046875 DR_Server Prod_server TCP 8888-54395 
30 3.046875 DR_Server Prod_server TCP 8888--54395 
31 3.046875 DR_Server Prod_server TCP 8888-54395 
32 3.046875 DR_Server Prod_server TCP 8888-54395 
33 3.046875 DR_Server Prod_server TCP 8888-54395 
34 3.046875 DR_Server Prod_server TCP 8888-54395 


图 2 

客户 斩钉截铁 , “你 看 一 目 了 然 吧 ，Wireshark 上 带 RST 标 志 的 包 明 
显 都 是 从 灾 备 服务 器 发 出 来 的 ， 所 以 就 是 你 们 的 设备 有 问题 ， 应 该 由 
你 们 来 负责 。*” 我 对 他 的 推理 无 力 反 驳 ， 的 确 应 该 到 灾 备 服务 器 上 检查 
配置 和 日 志 。 这 可 把 我 们 的 技术 文 持 急 坏 了 ， 因 为 他 在 灾 备 服务 器 上 
完全 查 不 出 问题 。 

我 们 似乎 走 进 了 一 条 死胡同 。Wireshark 把 原因 指 癌 了 灾 备 ， 但 我 
们 在 灾 备 上 又 没有 发 现 问 题 。 走 投 无 路 之 际 ， 我 只 好 从 头 再 梳理 一 
遍 ， 看 看 有 没有 漏 掉 什么 。 最 后 还 真 让 我 想到 一 个 可 能 性 一 一 虽然 在 
生产 服务 器 上 看 到 了 RST 包 ， 但 这 并 不 能 证 明 该 包 一 定 就 是 从 灾 备 发 过 
来 的 。 假 如 是 网 络 路 径 上 的 某 个 设备 伪装 成 灾 备 发 的 ， 那 就 不 算 我 们 
的 责任 啦 ， 应 该 在 两 边 的 服务 器 上 同时 抓 包 才能 判断 。 技 术 支 持 工程 
师 也 没有 更 好 的 办 法 ， 只 好 照办 了 ， 喜 讯 也 很 快 传 来 : 灾 备 那 边 果然 
没有 发 过 RST 包 ， 客 户 在 铁证 面前 也 认同 了 我 们 的 观点 。 这 足 任 推 扼 得 
堪 称 完美 。 

既然 和 我 司 无 关 ， 我 也 就 不 再 关注 这 件 事 情 了 。 没 想到 几 天 后 和 
同事 吃饭 时 ， 听 说 这 案子 还 没有 了 结 。 仔 细 打 听 了 一 下 ， 原 来 客户 不 
知道 怎样 定位 发 RST 的 那 台 设 备 ， 所 以 问题 还 是 解决 不 了 。 帮 人 帮 有 到 
底 ， 能 否 用 Wireshark 来 辅助 定位 呢 ? 我 们 研究 了 一 下 ， 发 现 还 是 可 以 
的 : 根据 RFC 1812， 一 个 网 络 包 的 TIL 每 减 去 1 就 意味 着 它 经 过 一 次 路 
由 。 接 下 来 我 们 再 看 图 3，RST 包 的 TTL 为 62。 由 于 TTL 的 初始 值 一 般 


seq=291 Win=262144 Len=0 
seq=291 Win=262144 Len=0 
Seq=291 Win=262144 Len=0 
Seq=291 Win=262144 Len=0 
seq=291 Win=262144 Len=0 
seq=291 Win=262144 Len=0 


为 64， 那 就 说 明 很 可 能 是 距离 生产 服务 器 两 跳 (64-62=2) 的 那 台 设备 
发 出 来 的 。 客 户 只 需 翻 出 网 络 拓扑 网 ， 头 能 大 概 知道 是 哪 台 设备 了 。 


No,. Time Source Destination Protocol Info 
27 3.042969 DR_Server Prod_server TCP 8888-~-54395 [ACK] seq=291 
28 3.042969 “Prod_server DR_Server TCP 54395~8888 [ACK] Seq=63¢ 
29 3.046875 DR_Server Prod_server TCP 8888-~-54395 [RST] Seq=29 
30 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] Seq=291 
31 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] Seq=291 
32 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] Seq=291 


* | Mi 


Identification: 0x000d (13) 
田 Flags: 0x00 


Fragment offset: 0 


Protocol: TCP (6) 


图 3 

这 个 案子 就 此 结束 了 ， 说 破 了 似乎 很 简单 ， 但 是 刚 遇 到 时 确实 很 
迷茫 。 事 实 上 当 我 想到 TTL 的 时 候 ， 已 经 意识 到 刚 开始 的 建议 是 不 对 
的 ， 没 必要 两 边 同 时 抓 包 ， 直 接 对 比 生产 服务 器 上 抓 到 的 正常 包 和 RST 
包 就 行 了 。 正 常 包 的 TTL 请 见 图 4， 说 明生 产 服务 器 和 灾 备 服务 器 之 间 
跨 了 6 跳 。 


pe | 


ime Source Destination Protocol Info 


No, 


3 DR_Server Prod_server 8888--54395 Seq=291 Ack=36477 Win=204 
28 3.042969 Prod_server DR_Server TCP 54395~8888 [ACK] Seq=63989 Ack=291 Win=13: 
29 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 
30 3.046875 DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 
31 3.046875 DR_server Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 
32 3.046875 DR_Server Prod_server TCP 8888--54395 [RST] Seq=291 Win=262144 Len=0 


站 | 中 


Identification: Ox6da6 (28070) 
田 Flags: 0x00 


Fraqment offset: 0 


图 4 

这 个 技巧 还 可 以 运用 到 其 他 的 场景 中 ， 比 如 前 几 天 有 朋友 说 百度 
的 JS 被 动 持 来 攻击 GitHub， 我 立即 告诉 他 可 以 抓 包 看 TTL。 后 来 该 方法 
被 国外 一 些 技 术 人 员 证 实时 ， 这 位 朋友 简直 惊 有 呆 了 ， 以 为 我 有 多 历 
害 。 其 实 我 是 先 花 了 很 多 时 间 在 这 个 案子 上 才 琢 磨 出 来 的 。 套 用 一 句 
有 扩 腊 的 心灵 鸡 淘 ， 束 是 “ 台 上 一 分 钟 ， 台 下 十 年 功 。” 


在 应 聘 一 个 技术 职位 之 前 ， 做 好 充分 的 准备 无 疑 能 大 大 提高 成 功 
率 。 这 里 所 说 的 准备 并 不 是 指 押 题 ， 因 为 有 经 难 的 面试 官 往往 准备 了 
海量 的 题库 ， 押 中 的 概率 太 低 。 比 如 我 有 位 同事 的 题库 里 有 上 百 道 
题 ， 内 容 洱 震 了 编程 、 操 作 系 统 、 网 络 、 存 储 .…… 每 次 他 束 抽 出 十 道 
来 问 ， 连 合作 多 年 的 我 都 狂 不 出 他 下 一 次 会 问 哪些 。 

那 完 竟 应 该 准备 什么 呢 ? 以 我 个 人 的 招聘 经 验 ， 最 值得 花 时 间 的 
束 是 总 结 目 己 过 去 的 工作 成 采 ， 因 为 这 在 面试 官 心目 中 有 举足轻重 的 
地 位 。 从 一 个 人 过 去 的 工作 经 历 中 ， 能 看 出 他 的 责任 心 、 鳃 研 精神 、 
技术 视野 、 交 流 能 力 ， 等 等 ， 比 知识 储备 更 有 价值 。 比 如 很 多 美国 的 
面试 家 喜欢 问 , “你 在 工作 中 明 到 过 什么 天 手 事情 吗 ? 最 后 是 怎么 解决 
的 ? ” 千 万 不 要 以 为 这 只 是 走过场 的 题目 而 随便 应 付 。 事 实 上 这 就 古 你 
发 挥 的 最 好 机 会 ， 正 确 的 表现 应 该 是 作 议 思 状 ， 稍 等 片刻 再 回答 ,“ 我 
处 理 过 不 少 有 挑战 性 的 问题 ， 比 如 有 天 xxx 的 ， 不 知道 您 对 这 方面 是 否 
感 兴趣 ? ”这 个 回答 会 显得 你 拿 得 出 手 的 东西 有 很 多 ，xxx 只 是 其 中 之 
一 。 也 不 用 担心 面试 官 会 对 它 不 感 兴 趣 ， 此 刻 他 们 正 伪装 成 无 所 不 知 
的 上 带 ， 无 论 你 说 什么 ， 他 们 都 会 显 出 很 懂 的 样子 ，“Wow， 这 是 很 知 
名 的 技术 ， 我 很 想 听 听 。” 于 是 你 事先 准备 好 的 材料 下 可 以 拿 出 来 显摆 
了 ， 要 牢记 以 下 几 扩 : 

"问题 插 述 要 引人入胜 。 确 保 这 个 若 手 的 问题 是 再 案 的 面试 官 部 能 
听 懂 的 ， 比 如 服务 器 访问 拒绝 、 网 络 性 能 下 降 ， 等 等 。 同 时 又 必须 足 
够 诡异 ， 比 如 同样 配置 的 两 台 服 务 占 表现 完全 不 同 。 你 多 看 几 期 《 走 
近 科 学 》， 束 能 理解 这 个 技巧 有 多 重要 ， 无 论 多 普通 的 事情 都 要 描述 
得 绘声绘色 。 只 要 勾 起 了 面试 官 的 好 奇 心 ， 他 们 隋 会 在 不 知 不 觉 中 和 
你 站 到 一 起 ， 而 不 是 居高临下 地 审问 。 


- 抓 住 互动 的 机 会 。 面 试 官 们 往往 会 妨 不 住 点 评 一 下 ， 甚 至 秀一 下 
知识 ， 这 是 技术 人 员 的 通病 。 要 抓 住 这 个 机 会 把 他 拉 进 来 讨论 ， 你 可 
以 这 样 附 和 ,“ 对 对 对 ， 我 当时 的 看 法 和 您 一 样 ， 但 是 .……” 一 起 探索 
同一 个 问题 非常 有 助 于 拉 近 你 们 的 心理 距离 。 

-拒绝 浮夸 。 真 实 的 内 容 才 可 能 让 有 经 验 的 面试 官 信服 。 假 如 让 对 
方 意识 到 有 添 油 加 酯 的 成 分 ， 肯 定 会 大 大 减 分 。 

:分 享 技术 。 这 些 案例 一 定 要 有 技术 含量 ， 比 如 最 终 在 Wireshark 中 
发 现 某 个 异常 现象 ， 再 结合 协议 细节 找到 了 根本 原因 。 这 样 可 以 让 面 
试 冒 在 学 习 到 新 知识 的 同时 ， 也 感受 到 你 的 钻研 精神 。 如 采 他 第 一 次 
见面 吏 能 从 你 这 里 学 到 有 价值 的 知识 ， 目 然 会 布 望 以 后 能 跟 你 一 起 工 
作 。 即 使 该 知识 对 他 没什么 实际 价值 ， 能 跟 一 个 有 钻研 精神 和 分 享 精 
神 的 人 合作 也 是 令 人 和 愉悦 的 。 

以 我 目 己 为 例 ， 我 多 年 前 应 聘 一 个 心仪 的 职位 时 ， 最 后 一 轮 的 面 
试 冒 是 个 美国 geek， 提 问 角 度 刁 钻 无 比 ， 因 此 我 大 多 没有 回答 出 来 ， 
现场 写 的 程序 也 出 错 了 。 最 后 他 估计 也 不 抱 厦 望 了 ， 象 征 性 地 让 我 讲 
讲 工 作 中 解决 过 的 灰 手 问题 ， 我 当时 很 不 识 相 地 说 , “我 遇 到 过 不 少 关 
于 TCP 协 议 的 ， 不 知道 您 是 否 有 兴趣 听 听 ? ” 没 想到 这 哥们 说 ,，“ 噢 ， 我 
的 博士 论文 束 定 和 TCP 协 议 有 天 的 ， 很 想 听 听 你 对 这 方面 的 见解 。? 我 
立即 慌 了 ， 屋 漏 偏 首 连 夜 雨 ， 吹 牛 磁 到 老 熟 人 ， 只 好 硬 着 头皮 讲 了 一 
个 杀 刁 经 历 过 的 性 能 优化 案例 。 神 奇 的 是 这 个 案例 竟然 改变 了 面试 结 
果 ， 正 因为 他 很 全 TCP， 所 以 对 这 个 问题 很 感 兴趣 ， 也 能 体会 我 在 优化 
过 程 中 的 努力 。 最 后 甚至 站 起 来 跟 我 讨论 了 很 多 细 市 ， 在 白板 上 画 了 
一 个 模型 图 跟 我 探讨 。 到 了 面试 结束 时 还 意犹未尽 ， 跟 我 说 了 一 句 意 
味 深长 的 话 ，“ 询 下 的 问题 等 你 来 上 班 继续 聊 。” 我 束 知 道 offer 到 手 了 。 
儿 周 后 我 第 一 天 上 班 ， 他 来 然 来 找 我 聊天 ， 其 中 有 一 句 话 我 至 今 还 记 
得 ,“ 虽 然 你 当时 有 很 多 问题 没 答 出 来 ， 但 是 最 后 那个 案例 体现 了 很 好 


的 钻研 精神 ， 让 我 意识 到 之 前 问 你 的 题目 没有 选 对 。? 面 试 官 们 真正 重 
视 的 是 什么 ， 由 此 可 见 一 班 。 

这 些 道理 听 上 去 很 商 单 ， 然 而 当 你 春 手 准备 面试 材料 的 时 候 ， 可 
能 会 发 现 没什么 拿 得 出 手 的 。 这 又 是 什么 原因 呢 ? 不 是 因为 你 平时 磅 
碌 无 为 ， 而 更 可 能 是 因为 没有 总 结 的 习惯 ， 时 间 一 长 都 乐 了 。 这 就 是 
坚持 写 技 术 博 客 的 价值 之 一 ， 能 用 目 己 的 语言 表达 出 来 才 算 真正 理解 
并 且 记 住 了 。 写 作 能 强迫 思考 ， 对 于 真正 有 技术 含量 的 东西 ， 你 会 在 
写作 过 程 中 加 深 理 解 ， 从 此 就 瑟 不 掉 了 ; 而 技术 含量 不 高 的 东西 ， 你 
写 个 开头 目 然 会 停 笔 ， 从 此 还 掉 也 无 所 谓 。 不 仅 技术 上 如 此 ， 其 他 学 
科 也 一 样 ， 年 轻 的 时 候 阅读 国学 经 典 ， 每 篇 都 让 人 和 觉得 顿悟 了 人 生 。 
但 如 果 试 着 把 感受 写成 文章 ， 束 会 发 现 所 谓 的 顿悟 只 是 一 碗 心灵 鸡 


全; Wireshark 


Wireshark 不 只 应 用 于 企业 级 数据 中 心 。 在 高 度 依赖 于 网 络 的 现代 
生活 中 ，Wireshark 也 有 广阔 的 用 武之 地 ， 匹 其 是 当前 越 来 越 流行 的 手 
机 应 用 。 这 一 部 分 介绍 了 如 何在 家 中 搭建 一 个 环境 来 抓 取 手机 上 的 
WiFi 网 络 包 ， 分 析 了 微 博 和 微 信 等 不 同 App 的 网 络 行为 ， 揭 露 了 家 庭 宽 
带 如 何 被 恶意 支持 等 。 这 一 部 分 技术 含量 不 一 定 很 高 ， 但 是 比较 有 
趣 o 


假 宽带 真相 


央视 的 【每 周 质量 报告 】 做 过 一 期 关于 网 络 的 节目 ， 叫 “ 假 宽 高 真 
相 ”。 大 意 是 说 某 些 运营 商 的 带宽 远 远 达 不 到 其 承诺 的 标准 ，360 的 测 
速 软 件 也 “有 明显 的 设计 缺陷 ”， 所 以 测 出 的 结果 远 高 于 真实 带宽 。 

难得 有 个 业内 大 新 闻 ， 我 当然 不 会 错过 ， 当 即 就 用 Wireshark 验 证 
了 一 下 。 这 一 试 才 知 道 ， 原 来 网 络 测速 包含 了 不 少 有 意思 的 知识 点 ， 
所 以 便 写 出 来 和 大 家 分 享 。 

我 家 当时 用 的 是 中 国电 信 的 10M 宽 带 ， 从 官网 测 到 的 结果 如 图 1 所 
示 ， 下 载 速度 达到 1235KB/ 秒 ， 差 不 多 是 10M 了 “。 在 不 同时 间 段 测试 都 
是 一 样 的 结果 ， 所 以 应 该 是 可 信 的 。 


带宽 莘 试 结果 : 未知 


本 次 测试 数值 : 平均 1235KBf 秒 ， 约 为 9_ 5M 带宽 。 
图 “同时 测 | 趟 上传 速率 


el 8 所 


了 村 蜀山 


加 下 载 速度 加 上 传 速度 
平均 值 : 12358B/ 秒 平均 值 : 271 了 /种 
峰 值 : 1419IB/ 种 峰 值 : 3331B/ 秘 
查看 带宽 换算 志 中 
图 1 


注意 中国 特色 的 宽带 服务 是 以 下 载 速度 为 计算 标准 的 ， 其 实 上 传 速度 慢 很 多 ， 上 下 行 带 
宽 严重 不 对 等 。 这 就 是 为 什么 会 在 图 1 中 看 到 上 传 速度 只 有 2M。 本 文 不 关注 这 一 点 ， 所 以 只 分 
析 下 载 速度 。 

这 个 速度 究竟 是 怎样 测 出 来 的 呢 ? 我 用 Wireshark 抓 了 个 包 ， 且 看 
下 面 的 详细 分 析 。 

点 击 Wireshark 的 Statistics 菜 单 ， 再 点 击 Conversations 选 项 ， 可 以 得 
到 图 2 所 示 的 窗口 。 从 中 可 见 测速 过 程 中 用 到 了 5 个 TCP 连 接 在 下 载 。 
为 端口 号 是 80， 所 以 应 用 层 协议 应 该 是 HTTP 。 


看 Te 
TT 
Ethernet: 3| Fibre Channel | Fppi| IPv4: 10 | Ipv6 | Ipx| JxTA] Ncp| Rsyp| 5GJp| TCP: 22 |Token Ring| upp:1| use| WLAN 


TCP Conversations 
Address A 4 port/ 上 4 AddressB 4 Port 4 pacl 4 Bytes v Packets A—B 4 BytesA—B 4 Packets A~B 4 Byte: ^ 
192.168.0.102 54350 101.95.50.3 80 6901 2662 158 118 4239 ( 国 
192.168.0.102 ”54351 101.95.50.3 80 5868 2267 134 727 3601 
192.168.0.102 ”54347 101.95.50.3 80 4649 1835 109 741 2814 
80 
80 


192.168.0.102 54348 101.95.50.3 4064 1573 92 992 2491 
192.168.0.102 ”54346 ”101.95.503 3 281 1221 72 264 2060 


Name resolution 四] Limit to display filter 


图 2 

为 什么 要 选择 5 个 连接 ， 而 不 是 更 多 或 者 更 少 昵 ? 其 实 连接 数 的 选 
取 很 有 讲究 。 之 所 以 不 用 单个 连接 ， 是 因为 一 个 连接 不 可 能 时 刻 都 在 
传输 ， 有 很 多 原因 会 导致 它 不 得 不 短暂 停 注 。 当 某 一 个 连接 集注 时 ， 
其 它 的 连接 还 可 以 继续 传输 ， 这 样 承 能 最 大 限度 地 利用 带宽 。 在 《 固 
定 宽带 接 入 速率 测试 方法 》 通 信行 业 标 准 中 ， 也 明确 规定 了 “测试 中 使 
用 的 线程 数量 为 N (N>4) ”。 

图 3 是 其 中 一 个 连接 的 Time/Sequence Number 坐标 图 ， 我 是 在 
Wireshark 中 点击 Statistics 一 TCP StreamGraph 一 Time-Sequence Graph 

(Stevens) 菜单 来 生成 它 的 。 


一 
顾 TCP Graph 2: download.pcapng 101.95.50.3:80 — 1 
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图 3 

对 这 个 连接 而 言 ， 传 输 过 程 中 遭遇 了 多 次 停滞 ， 比 如 最 严重 的 是 
0.3 一 7.8 秒 之 间 ，Sequence 值 几乎 没有 增长 。 还 好 其 他 TCP 连 接 在 这 段 
时 间 里 仍 在 正常 传输 ， 所 以 带宽 一 点 都 没有 浪费 。 之 所 以 没有 用 更 多 
的 连接 数 ， 是 因为 多 到 一 定 程度 就 没有 意义 了 ， 甚 至 会 影响 TCP 的 拥塞 
控制 效果 。 我 用 iPerf 测 试 过 的 ， 详 情 可 见 本 书 的 《过 犹 不 及 》 一 文 。 
究竟 用 多 少 个 连接 数 最 好 ， 这 是 需要 测试 的 ， 佑 计 技 术 人 员 测 下 来 的 
最 佳 连接 数 是 5。 随 着 百 兆 家 庭 带 宽 的 普及 ， 相 信 我 们 以 后 会 看 到 更 多 
的 连接 数 。 

再 回 到 Wireshark 的 主 界面 。 如 图 4 所 示 ， 在 下 载 测试 开始 之 前 ， 客 
户 端 是 用 一 个 GET 方 法 查 到 下 载 源 的 ， 即 http:/101.95.50.3/testimg。 直 


接 用 IP 的 办 法 不 错 ， 因 为 不 会 受到 DNS 查 询 时 间 的 影响 。 


No. Time Source Destination Protocol Info 
9 0.300174000 192.168.0.102 218.1.60.39 HTTP GET /speed/P1uginAccessLimit. do?method=acquire&uip=KD10230 
10 0.304187000 218.1.60.39 192.168.0.102 TCP [TCP Dup ACK 8#1] 80-54345 [ACK] Seq=266 Ack=1558 Win=8704 
11 0.304189000 218.1.60.39 192.168.0.102 TCP 80-54345 [ACK] Seq=266 Ack=3138 Win=11520 Len=0 


12 0.327770000 218.1.60.39 192.168.0.102 HTTP HTTP/1.1 200 OK (application/json) 
sse | ny ee EE EE mi EE ee ms 
9 Object 
日 Member Key: “id” 
string value: 6585031 
日 Member Key: 


"ur1” 
String value: lhttp://101.95. 50.3/test. img 


图 4 

获知 下 载 源 之 后 ， 就 可 以 建立 5 个 TCP 连 接 下 载 了 。 图 5 是 其 中 的 一 
个 连接 ， 从 Time 一 栏 可 见 响应 速度 相当 快 ，GET 请 求 发 出 去 3.1 毫 秒 后 
( 即 16 号 包 和 18 号 包 之 间 的 时 间 差 ) 就 开始 收 到 数据 了 。 这 是 因为 
it 离 我 家 不 远 。 而 且 这 应 该 是 一 台 专 
门 用 来 提供 测速 的 服务 器 ， 很 可 能 被 全 面 优化 过 了 “。 不 过 再 怎么 优化 
都 不 算 作 弊 ， a 。 看 来 央视 
曝光 的 假 带 宽 问 题 没有 发 生 在 我 身上 。 


No, Time Source Destination Protocol Info 
13 0.420906000 192.168.0.102 101.95.50.3 TCP 54346-~80 [SYN] seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PE 
14 0.424337000 101.95.50.3 192.168.0.102 TCP 80-54346 [SYN, ACK] seq=0 Ack=1 Win=14600 Len=0 MSS=1412 
15 0.424425000 192.168.0.102 101.95.50.3 TCP 54346-80 [ACK] Seq=1 Ack=1 Win=66364 Len=0 
16 0.426084000 192.168.0.102 101.95.50.3 HTTP GET /test.img?q=0.2612285758368671 HTTP/1.1 
17 0.428562000 101.95.50.3 192.168.0.102 TCP 80-~54346 [ACK] Seq=1 Ack=415 Win=15744 Len=0 
18 0.429200000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
19 0.429270000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
20 0.429299000 192.168.0.102 101.95.50.3 TCP 54346-~80 [ACK] Seq=415 Ack=2825 Win=66364 Len=0 
21 0.429380000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
22 0.429520000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
23 0.429545000 192.168.0.102 101.95.50.3 TCP 54346--80 [ACK] Seq=415 Ack=5649 Win=66364 Len=0 
24 0.429638000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
25 0.429809000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 


图 5 
注意 : 高 带宽 并 不 意味 着 上 什么 网 都 快 。 影 响 性 能 体验 的 因素 很 多 ， 除 了 带宽 ， 还 有 跨 运 
营 商 、 跨 区 域 和 服务 器 性 能 等 。 就 算 你 家 里 有 100M 宽 带 ， 靠 VPN 连 到 国外 网 站 看 视频 也 可 能 
很 卡 。 
那 作为 第 三 方 的 360 测 速 软件 是 否 真 的 “有 了 明显 的 设计 人 缺陷” 呢 ? 我 
下 载 到 了 两 个 360 测 速 软件 ， 先 来 看 第 一 个 。 如 图 6 所 示 ， 测 出 来 的 市 
宽 为 8M， 略 低 于 电信 和 官网 的 宣称 值 。 


如 网 志 测 试 工具 x 
当前 网 络 环境 下 , 下 载 的 速度 能 达到 : 1i1MB/ 种 


损 呈 “Sl 


[i 网 速 测试 结果 说 明 


您 的 网 束 在 : 8M ADSL 和 专线 之 间 。 
属于 较 快 的 宽带 上 网 速度 范围 内 ， 能 流畅 的 浏览 网 页 ， 看 在 线 视频 和 玩 网 络 游 
戏 。 


》 网 速 不 错 ? 通过 论坛 、 微 博 告 听 其 他 人 》 测速 结果 保存 为 图 片 
“~ 加 快 上 网 速度 的 建议 


通常 不 会 受到 占 网 速 程序 的 景 弗 ， 但 如 果 感 觉 上 网 速度 出 现 异 常 、 绎 慢 的 情况 ， 
可 以 定期 查看 流量 点 控 。 


重新 测试 | | 退出 


图 6 

于 是 再 用 Wireshark 分 析 。 从 图 7 可 见 ，360 测 速 软件 也 选择 了 5 个 
TCP 连 接 来 下 载 ， 端 口号 也 是 80， 与 电信 的 方式 如 出 一 纹 。 原 理 是 一 模 
一 样 ， 差 别 只 是 服务 器 的 啊 应 速度 ， 电 信服 务 堪 为 3.1 毫 秒 ，360 服 务 器 
则 是 4.9 毫 秒 ， 这 也 许 就 是 结果 略 有 不 同 的 原因 。 有 具体 网 络 包 和 图 5 很 
像 ， 为 了 不 浪费 篇 幅 我 就 不 贴 出 来 了 。 


TCP Conversations 
Address A 4 PortA 4 AddressB 4 PortB 4 Packets 4 Bytes Y PacketsA 一 B 4 BytesA 一 B 4 Packets A~B 4 Bytes A~B 14 
192.168.0.102 52618 101.227.15.3 80 1106 741 265 
192.168.0.102 52619 101.227.15.3 80 1013 720883 
192.168.0.102 52617 101.227.153 80 995 714 789 
192.168.0.102 52616 ”101.22715.3 80 1008 698 025 
192.168.0.102 101.22715.3 80 


网 Name resolution Limit to display filter 


从 这 个 工具 看 ，360 测 速 软件 并 不 存在 央视 所 说 的 “明显 的 设计 缺 
陷 ”， 否 则 电信 官网 也 算 设 计 缺 陷 。 于 是 我 决定 试 一 下 另 一 个 360 测 速 
工具 。 从 图 8 可 见 ， 其 结果 接近 10M 。 


多 360 宽 带 测速 器 创建 点 面 图 标 | 微 博 分 享 X 


席 带 接 入 速度 长 途 网 络 速 度 ” 网 速 排行 榜 


按 号 512k 宽带 ”1M 窝 带 ”2M 帘 带 ”4M 窜 带 10M 宽带 ”专线 


当前 的 网 速 就 像 淡 租 的 速度 ， 领 先 于 全 国 95% 的 用 户 ! 


25) 这 期 网 速 如 按 次 显示 J 按 天 显示 


1,5MIB 下 载 速 度 为 1.21 MB/ 种 


图 8 

再 用 Wireshark 分 析 。 从 图 9 可 见 ， 这 次 除了 HTTP 下 载 ， 还 有 不 少 
数据 是 通过 P2SP 的 ， 传 输 层 走 的 是 UDP 协议 。 央 视 的 专家 估计 也 看 到 
这 个 现象 ， 所 以 认为 这 是 一 个 设计 缺陷 ， 说 “这 种 P2SP 测 速 方法 ， 它 会 
去 选择 一 些 同样 安装 了 这 款 软件 的 其 他 的 连接 节点 来 进行 测速 ， 只 
其 中 有 一 个 节点 ， 它 是 在 这 个 用 户 同 一 个 小 区 宽带 的 子 网 里 面 ， 它 的 
这 个 链 路 质量 就 非常 好 ， 网 速 就 非常 快 *。 我 有 点 怀疑 这 个 猜测 ， 因 为 
一 个 小 区 里 有 多 个 用 户 安装 测速 软件 的 概率 太 低 了 。 我 自己 测 了 几 次 


的 结果 都 甜 不 多 ， 假 如 真有 一 个 节点 在 我 们 小 区 里 ， 应 该 能 从 图 9 的 统 
计 表 中 看 出 这 个 “ 作 星 "IP 的 流量 。 
一 CSS ER 王国 


| Etheret: 5| Fibre channel Fppi| jpv4: 378| Ipv6| Ipx| xra| Ncp| Rsyp| scTp| Tcp:84| Token Ring| UDP: 353 use | 


UDP Conversations 

AddressA 4 portA 4 AddressB 4 PortB 4 Pacl 4 Bytes v PacketsA—B 4 BytesA—B 4 Packets A~B 4 Byt 
106.118.175.90 61487 ”192.168.0.102 10102 591 529147 401 513 221 190 
192.168.0.102 10102 182.200.188.88 10100 468 462142 133 11 230 335 
192.168.0.102 10102 113.26.217.39 10100 465 453 782 138 11 849 327 

| 14.208.249.79 10106 192.168.0.102 10102 265 232417 172 224 463 93 

| 192.168.0.102 10102 113,69.20.255 1948 273 231 636 186 224 613 87 
42.92.132.89 10640 192.168.0.102 10102 240 218815 162 212 164 78 

由 | 180.111.109.197 10102 192.168.0.102 10102 198 196174 57 4603 141 

图 9 


综 上 所 述 ，360 测 速 软件 还 是 有 市 操 的 ， 它 体现 的 是 模拟 现实 的 网 
速 ， 包 括 HITP (浏览 网 页 和 刷 微 博之 类 的 ) 和 P2SP (比如 迅雷 下 
载 ) 。 运 营 商 提供 的 测速 也 没有 作 浆 ， 不 过 它 体现 的 是 一 个 接近 理想 
状况 的 网 速 。 那 为 什么 央视 说 有 些 宽 带 不 达标 ， 但 360 测 速 软件 却 给 出 
很 高 的 带宽 呢 ? 我 认为 这 不 是 P2SP 导 致 的 ， 而 是 因为 这 些 运 营 商 侦查 
ee ， 于 是 立即 支持 ， 转 变 成 在 限 速 点 之 内 测速 了 。 如 果真 

这 样 ， 那 也 是 运营 商 的 问题 ， 不 能 怪 测速 工具 。 由 于 我 没 抓 到 这 种 
A 所 以 就 不 多 作 评 论 。 

最 后 声明 一 下 ， 我 写 这 篇 文章 的 目的 不 是 给 上 海 电信 做 广告 或 者 
为 360 正 名 ， 只 是 想 借助 这 个 话题 沉 示 一 下 Wireshark 的 应 用 场景 。 儿 乎 
所 有 和 网 络 相关 的 问题 都 可 以 用 Wireshark 来 探索 学 习 ， 有 时 候 稍 微分 
析 一 下 就 能 看 得 很 远 。 我 对 带宽 缺 斤 短 两 也 不 在 乎 ， 因 为 从 来 不 下 载 

电影 或 者 美剧 。 网 络 的 安全 和 通畅 才 是 我 最 重视 的 ， 可 惜 这 两 点 并 不 
容易 享受 到 。 


手机 抓 包 


我 很 久 以 前 就 想 在 手机 上 抓 包 了 “。 因 为 随 着 移动 App 的 流行 ( 见 图 
1) ， 手 机 的 流量 越 来 越 大 ， 值 得 研究 的 技术 问题 也 会 越 来 越 多 。 像 我 
这 样 还 未 融入 现代 社会 的 大 权 ， 每 个 月 都 能 用 掉 几 百 兆 流量 ， 那 些 摩 
登 青 年 的 流量 之 大 可 想 而 知 。 


图 1 

不 过 作为 晚期 拖延 症 患 者 ， 我 迟 迟 没有 付 诸 行 动 ， 直 到 有 一 天 手 
机 上 的 某 个 App 英 名 其 妙 地 耗 挥 了 近 百 兆 流量 ， 才 不 得 不 动手 。 我 先 打 
了 个 电话 给 中 国 移动 ， 客 服 人 员 说 ,，“ 我 们 最 近 收 到 很 多 例 类 似 的 报告 
了 ， 原因 还 没有 查 明 。” 好 吧 ， 看 来 只 能 由 我 自己 来 查 了 ， 顺 便 搭建 一 
个 可 以 在 手机 上 抓 包 的 环境 。 

一 番 研 究 之 后 ， 我 大 概 知道 了 业内 人 士 都 是 怎么 抓 包 的 。 

.多 数 开 发 人 员 用 Fiddler 和 Charles 来 抓 ， 包 括 安 卓 和 iPhone。 可 惜 
它们 都 是 针对 Web 的 ， 不 能 满足 我 的 全 部 需求 。 

:有 人 说 设 个 HTTP 代 理 就 可 以 在 电脑 上 抓 了 ， 不 过 我 感 兴 趣 的 协议 
不 只 是 HTTP 。 

.有 一 些 现 成 的 安 卓 抓 包 工具 ， 但 需要 root 才 能 装 。iOS 上 的 工具 出 
没有 找到 。 

. 搜 到 了 一 鞭 叫 tPacketCapture 的 工具 ， 号 称 无 需 root 也 能 抓 ， 可 是 
我 的 安 章 测试 机 上 不 了 Google Play。 


真 没 想到 手机 抓 包 这 么 麻烦 ， 相 比 之 下 电脑 抓 包 实在 太 方 便 了 ， 
只 要 闭 个 Wireshark 束 行 ， 分 分 钟 搞 定 。 那 有 没有 办 法 用 Wireshark 来 抓 
手机 上 的 包 呢 ?这 个 问题 让 我 想起 了 大 学 寝室 的 网 络 拓扑 ， 当 时 我 们 
禄 室 四 个 人 只 共享 一 个 对 外 的 网 口 ， 所 以 就 在 我 的 电脑 上 装 了 两 个 网 
卡 ， 网 卡 1 对 外 ， 网 卡 2 和 室友 们 的 电脑 连 在 一 个 交换 机 上 ， 如 图 2 所 
染 才 


我 的 电脑 小 徐 的 电脑 小 陈 的 电脑 小 顾 的 电脑 


图 2 

这 样 室 友 们 的 对 外 流量 就 是 通过 我 的 “网 卡 2 一 网卡 1” 出 去 了 ， 理 
论 上 只 要 在 我 的 网 卡 上 抓 包 ， 就 能 知道 哪 位 室友 在 和 女神 聊 QQ， 哪 位 
室友 在 祝 楼 主 好 人 一 生平 安 了 (兄弟 们 馈 命 ， 我 就 说 说 而 已 ， 没 有 真 
抓 过 ) 。 假 如 把 我 家 的 网 络 拓扑 也 改 成 这 样 ， 让 手机 也 通过 我 的 电脑 
上 网 ， 不 就 可 以 用 Wireshark 抓 到 手机 连 WiFi 时 的 包 了 吗 ? 当前 我 家 的 
网 络 拓 扑 如 图 3 所 示 ， 手 机 的 网 络 包 都 通过 无 线路 由 器 出 去 了 ， 我 得 改 
造 一 下 ， 让 它们 走 一 台 已 经 淘汰 不 用 的 台式 机 。 


入 户 modem 


无 线路 由 器 


= 了 7 = 


淘汰 的 台式 机 


有 线 连 接 
- - - - 无线 连接 


iPhone 安 早 


图 3 

线路 改造 只 花 了 几 分 钟 : 我 先 把 无 线路 由 器 撤 掉 ， 再 把 入 户 
modem 直 接连 到 台式 机 的 网 卡 1 上 ， 这 样 台式 机 就 可 以 上 网 了 。 接 下 来 
只 要 把 台式 机 的 网 卡 2 (无 线 的 ) 设 为 热点 ， 就 能 供 手机 上 网 了 。 网 络 
拓扑 如 图 4 所 示 。 


入 户 modem 


淘汰 的 台式 机 


一 一 一 一 有 线 连 接 
一 一 一 -~ 无 线 连接 


iPhone 安 早 
图 4 
接 下 来 的 配置 过 程 复杂 一 点 ， 但 也 说 不 上 很 难 。 
1. 执行 图 5 的 命令 ， 将 台式 机 的 无 线 网 络 设 成 热点 。 


rt wlan set hostednetwork mode=all ssid=wireless key=12345678 


:Nse 
网 和 模式 设置 
网 * 
i 


:Jsers\dministrator>netsh wlan start hostednetwork 


已 启动 举 载 网 络 。 


4 U4 


图 5 
2. 把 台式 机 的 网 卡 1 共 享 给 无 线 网 络 ， 如 图 6 所 示 。 


Internet 村 接 共享 
主 其 通过 bi ernet ] 
回 多 注 基 全 络 用 户 通过 此 计算 机 的 Int t 连接 


家 庭 网 络 连 接 00 : 
无 线 网 络 连 接 2 


失重 全 后 用 户 这 机 叶柄 用 共事 的 Internet ] 主 
ICS (Internet ] 车 接 共 误 [设置 (6)... | (6) 


3， 此 时 控制 面板 中 应 该 可 以 看 到 4 个 连接 ， 如 图 7 所 示 。 


办 一 口 x 
| | 


DC | uintene\RS 和 二 ||| 加 BS | 
组 织 > -| 


本 地 连接 2 
Ma 网 络 , 共享 的 Re 网 络 电线 被 拔 出 


os Reaktek RTL8168D/8111D 系列 .. 多 dS TAP-Windows Adapter V9 


无 线 网 络 连 接 无线 网 络 连接 2 
未 连接 wireless 
| DW1501 Wireless-N WLAN Ha... | Microsoft Virtual WiF Minipor... 


图 7 
4. 在 手机 上 扫 到 热点 ， 输 入 密码 就 连 上 了 ， 如 图 8 所 示 。 
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Cancel Add Network ManyuUu... Save 


Network SSID 


wireless 


Security WPA/WPA2 PSK 


12345678 


Advanced Options 


图 8 


5. 在 台式 机 上 打开 Wireshark， 从 Capture Interfaces 可 以 看 到 4 个 连 
接 ， 义 上 我 们 感 兴趣 的 无 线 网 络 就 可 以 了 ， 本 地 连接 没 必要 抓 。 注 意 
有 些 老 版 本 的 Wireshark 是 抓 不 到 无 线 网 络 包 的 ， 你 也 许 需 要 升级 到 最 
新 版 本 。 


邓 Wireshark: Capture Interfaces [ss Ee 
Device Description Pp Packets Packets/s 
| | 芯 | 无 线 网 络 连接 2 ”Microso 代 fe80::74d3:70ae:dba5:55d6 0 0 
亏 | 本 地 连接 Realtek RTL8168D/8111D PCI-E Gigabit Ethernet NIC fe80::9cd5:1f56:1icd:25f4 4 0 
扇 | 无 线 网 络 连 接 。 Microso 代 fe80::38f3:ecd7:8e:5b78 0 0 
扎 | 本 地 连接 2 TAP-Windows Adapter V9 fe80::4d45:59a0:bl0e:961f 0 0 


Start Stop Qptions Close 


图 9 

以 上 步 又 仅 供 参考 ， 因 为 在 不 同 的 环境 中 ， 即 使 严格 遵循 这 些 步 
又 也 有 失败 的 可 能 ， 比 如 有 些 无 线 网 卡 天 生 就 不 支持 当 热 点 。 我 还 过 
到 过 一 个 问题 ， 束 是 在 第 4 步 时 手机 一 直 连 不 上 ， 抓 包 看 到 它 发 了 很 多 
DHCP 请 求 给 合式 机 ， 但 是 没有 得 到 回复 ， 如 图 10 所 示 。 


[No. Time 


Source Destination Protocol Info 
950 97.044089000 0.0.0.0 2 DRer DHCP Discover - Transaction 
953 100.052233000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction 
957 109.057178000 0.0.0.0 2 DEP DHCP Discover - Transaction 
1035 125.056014000 0.0.0.0 255.255.25525255 ‘DHCPF DHCP Discover - Transaction 
1055 157.064822000 0.0.0.0 255.23553.255..255 "DHCP DHCP Discover - Transaction 
1060 160.075296000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction 
UL 


习 Frame 950: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 
日 Ethernet II, Src: d0:df:9a:cf:88:30 (dO:df:9a:cf:88:30), Dst: ff:ff:ff:ff:ff:ff CFf:ff: -一 下 
四 Destinmation®s 二 fo FE 下 下 TFT RF 《FF 下 人 个 FF 下 三 人) 
四 Source: d0:df:9a:cf:88:30 (d0:df:9a:cf:88:30) 
Type: IP (0x0800) 


图 10 

为 了 节省 时 间 ， 我 没有 去 研究 解决 DHCP 的 问题 ， 而 是 在 手机 上 人 
工 配置 了 IP。 如 果 你 比 我 还 懒 ， 甚 至 可 以 连 1、2、3 步 都 不 做 ，Google 
一 下 “无 线 网 卡 +WiFi 热 点 "， 找 一 些 软件 来 自动 完成 这 些 步 又。 不 过 这 
样 做 可 能 遇 到 流氓 软件 ， 安 全 性 不 能 保证 。 


这 次 网 络 改造 非常 值得 ， 因 为 从 此 家 里 每 个 手机 的 网 络 包 都 可 以 
用 Wireshark 抓 到 了 ， 使 我 更 有 动力 去 研究 手机 网 络 。 比 如 我 想 知 道 手 
机 开机 后 的 第 一 个 网 络 动作 是 什么 ， 抓 个 包 残 一目了然。 从 图 11 可 
见 ， 它 先 通 过 DNS 查 询 NTP 服 务 器 的 IP 地 址 ， 然 后 就 发 NTP 包 去 同步 时 
间 了 。 这 就 是 为 什么 手机 时 间 用 不 着 调整 ， 但 是 走 得 比 江诗丹顿 还 
准 。 至 于 本 文 开头 提 到 的 那个 耗 流量 App， 原 来 是 因为 它 不 停 地 刷 某 个 
网 页 人 被 我 删 扩 了。 


No. Time Source Protocol Info 
4 0.086701000 Android 和 p= alidns DNS standard query Ox a.pool.ntp.org 
5 0.095904000 人 ub1icl.alidns.com Android DNS standard query respon se Ox be A 194.27.44.55 
6 0.100035000 Android asia. poo ol.ntp.org NTP NTP Version 3, cli 
31 3.546978000 asia.pool.ntp.org Andro NTP NTP Version 3, server 


图 11 


> ] 人 


不 知道 为 什么 ， 我 的 微 博 有 时 候 会 很 卡 ， 比 如 刷新 时 会 一 直 
Loading ( 见 图 1) 。 这 不 只 是 我 的 个 人 感受 ， 很 多 网 友 都 抱怨 过 。 而 装 
在 同一 个 手机 上 的 微 信 ， 连 的 也 是 同一 个 WiFi， 却 没有 这 个 症状 。 虽 
然 这 个 问题 出 现 的 并 不 频 索 ， 但 假如 我 是 微 博 的 开发 人 员 ， 肯 定 要 把 
原因 找 出 来 。 
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图 1 


当 我 的 手机 抓 包 环 境 搭 好 时 ， 第 一 个 想 解决 的 问题 就 是 这 个 。 我 
随意 发 了 一 条 微 博 ， 虽 然 没 有 碰 到 卡 顿 ， 但 还 是 把 包 抓 下 来 了 。 开 头 
儿 个 网 络 包 如 图 2 所 示 。 


No， Time Source Destination Protocol Info 
1 0.000000000 Android DNS_Server DNS standard query Ox917c A api.weibo. cn 
3 0.009664000 DNS_server Android DNS standard query response Ox917c CNAME weibo.cn 
4 0.011417000 Android weibo. cn TCP 48658-80 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 : 
7 0.044534000 weibo.cn Android TCP 80-48658 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=( 
8 0.045467000 Android weibo. cn TCP 48658-80 [ACK] Seq=1 Ack=1 Win=14720 Len=0 
图 2 


我 又 发 了 一 条 测试 私信 ， 可 惜 也 没有 卡 顿 。 开 头 几 个 网 络 包 如 图 3 
所 示 。 


No. Time Source Destination Protocol Info 


1 0.000000000 Android DNS_Server DNS standard query Ox860b A ps.im.weibo.cn 
2 0.009506000 DNS_server Android DNS standard query response Ox860b A 180.149.134.252 
3 0.011703000 Android ps.im.weibo.cn TCP 42555-8080 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 5s, 
4 0.040482000 ps.im.weibo.cn Android TeR 8080-42555 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 
5 0.041463000 Android ps.im.weibo.cn TCP 42555~8080 [ACK] Seq=1 Ack=1 Win=14720 Len=0 

图 3 


虽然 两 次 都 没有 重 现 问 题 ， 但 是 从 网 络 包 可 见 ， 微 博 的 工作 方式 
严重 依赖 DNS。 它 在 调用 任何 功能 之 前 都 要 先 向 DNS 服 务 器 查询 ， 得 
到 提供 该 功能 的 服务 器 IP， 然 后 再 建立 TCP 连 接 。 最 神奇 的 是 它 不 会 组 
存 查 询 结 果 ， 所 以 需要 频繁 地 重复 查询 DNS。 我 才 抓 了 两 分 钟 包 ， 竟 
然 束 看 到 了 上 百 个 查询 ， 这 会 不 会 就 是 微 博 卡 顿 的 原因 呢 ? 我 又 抓 了 
一 个 发 微 信 的 包 作对 比 ， 如 图 4 所 示 


No, _ Time Source Destination Protocol Info 


Le 


1 0.000000000 Android 1 472 上 3 TCP 37613-~80 [SYN] Seq=0 Win=14000 Len=0 MI: 

2 0.033016000 14,.17.52.137 Android TCP 80-~37613 [SYN, ACK] Seq=0 Ack=1 Win=14. 

3 0.034825000 Android 14.17. 52.137 TCP 37613-80 [ACK] Seq=1 Ack=1 Win=1792000 
图 4 


果然 ， 微 信 客 户 端 直接 就 和 一 个 IP 地 址 建立 了 连接 。 we 文 个 IP 是 
写 在 配置 文件 中 的 ， 还 是 之 前 就 存在 手机 的 缓存 里 的 ， 这 至 少 说 明了 
微 信 不 像 微 博 那 样 依赖 DNS。 

为 了 进一步 验证 这 个 猜测 ， 我 故意 把 手机 上 的 DNS 服务 器 配 成 一 
个 不 存在 的 地 址 。 不 出 所 料 ， 微 信 还 是 能 照常 工作 ， 但 人 微 博 就 再 也 刷 
不 出 来 了 。 之 前 我 手机 上 配 的 DNS 服务 器 位 于 美国 ， 可 能 有 时 候 跨 国 


连接 不 稳定 ， 所 以 导致 了 微 博 的 卡 顿 现 象 。 考 虑 到 这 一 点 ， 我 尝试 配 
了 一 个 国内 的 DNS 〈 见 图 5) ,果然 从 此 再 也 没 卡 过 了 ， 刷 起 来 异常 流 
畅 。 


Static IP Address Y 


IP Address 


Gateway 


Network Prefix Length 


DNS 


图 5 

当 你 看 到 这 篇 文革 的 时 候 ， 也 许 这 个 问题 已 经 被 新 浪 解 决 了 ， 因 
为 我 已 经 向 微 博 的 技术 人 员 反 馈 过 (或 者 他 们 早已 经 知道 ) 。 相 信和 解 
决 起 来 也 不 复杂 ， 只 要 像 微 信 一 样 缓存 IP 束 可 以 了 。 据 我 所 知 ， 苹 果 
的 App Store 和 人 小米 电视 也 遭遇 过 DNS 导致 的 性 能 问题 ， 所 以 相信 还 有 
很 多 设备 或 者 程序 可 以 利用 Wireshark 来 优化 ， 只 要 把 使 用 过 程 的 包 都 
抓 下 来 ， 说 不 定 就 能 发 现 值 得 改进 的 地 方 。 


最 后 再 补充 一 个 小 发 现 。 我 发 的 微 博 内 容 是 “capture test，will 
delete it soon.”， 分 享 范围 设 成 * 仅 自己 可 见 ”。 没 想到 在 Wireshark 上 直 
接 束 看 到 了 明文 ( 见 图 6 底部 ) ， 发 私信 就 没有 这 个 问题 。 因 此 我 们 连 
公共 WiFi 发 微 博 的 时 候 ， 还 是 要 小 心 一 点 。 不 要 以 为 设 成 “分 组 可 见 ” 
或 者 “ 仅 目 己 可 见 ? 束 够 私密 了 ， 其 实在 Wireshark 上 都 能 看 到 。 


No, Time Source Destination Protocol Info 


36 0.097649000 weibo.cn Android TCP 80-48658 [ACK] Seq=1 Ack=1538 Win=19968 Len=0 
37 0.099154000 Android weibo. cn TCP [TCP segment of a reassembled PDU] 

38 0.099310000 Android weibo. cn HTTP POST /2/statuses/send?uicode=10000017&c=android 
39 0.100289000 weibo. cn Android TCP 80-48658 [ACK] Seq=1 Ack=1703 Win=21248 Len=0 


40 0.100330000 weibo. cn Android TCP 80-48658 [ACK] Seq=1 Ack=1913 Win=22656 Len=0 
< LL 


lain 


J Line-based text data: text/p 
Capture test\327\274\214w 


寻找 HttpDNS 


这 几 年 互联 网 行业 有 多 火 ? 假如 有 块 陨 石 掉 进 创业 园区 ， 说 不 定 
能 砸 到 两 位 互联 网 架构 师 ;， 要 是 没 学 会 几 句 互联 网 黑 话 ， 你 都 不 好 意 
思 说 自己 是 搞 芽 的 。 不 久 前 就 有 位 架构 师 在 技术 群 里 讨论 秘 厂 ( 黑 
话 ， 即 腾讯 公司 ) 的 HtpDNS， 令 我 自 必 形 秘 ， 因 为 这 个 词 我 从 来 没有 
听 说 过 。 

为 了 掩饰 自己 的 孤 陋 址 闻 ， 我 悄悄 做 了 点 功课 ， 发 现 这 技术 还 所 
有 趣 的 。 而 要 学 习 它 ， 就 得 从 最 传统 的 DNS 开 始 说 起 。 

我 们 都 知道 上 网 的 时 候 需 要 先 把 域名 解析 成 IP 地 址 ， 比 如 我 在 浏 
多 妖 中 输入 www.qq.com 再 按 回 车 ， 就 会 通过 DNS 查 询 到 该 域名 所 对 应 
的 PP， 然后 再 与 之 建立 连接 。 但 是 很 多 人 并 不 知道 ，DNS 的 解析 结 
是 很 智能 的 。 对 于 同一 个 域名 ， 上 海 电 信 的 用 户 一 般 会 解析 到 属于 上 
海 电 信 的 卫 地 址 ; 北京 联通 的 用 户 一 般 会 解析 到 属于 北京 联通 的 卫 地 
址 。 请 看 下 面 两 个 天 于 www.qdq.com 的 不 同 解析 结 


上 海 电 信用 户 解 析 到 了 101.226.129.158 ( 见 图 1) 。 经 查证 ， 该 IP 
属于 上 海 电 信 山 。 


Fiter | | Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
1 0.000000000 Dianxin_Client Dianxin_Local_DNS DNS standard query Ox0002 A www.qq. com 
2 0.004274000 Dianxin_Local_DNS Dianxin_Client DNS standard query response Ox0002 A 101.226.129.158 
图 1 


甬 用 户 解析 到 了 61.135.157.156 ( 见 图 2) 。 经 查证 ， 该 IP 属 


Filter: [| Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
1 0.000000000 Liantong_Client Liantong_Local_DNS DNS standard query Ox0002 A www.qq. com 
2 0.033494000 Liantong_Local_DNS Liantong_Client DNS standard query response Ox0002 A 61.135.157.156 
图 2 


这 个 智能 技术 是 怎样 实现 的 呢 ? 原 来 DNS 支 持 GSLB (Global 
Server Load Balance， 全 局 负载 均衡 ) ， 能 根据 DNS 请 求 所 包含 的 源 地 
址 返回 最 佳 结果 ， 从 而 匹配 同 地 区 、 同 运营 商 的 卫 ， 使 用 户 体验 到 最 
好 的 性 能 。 图 3 演示 了 这 个 解析 过 程 。 


Www. Www.qq.com? 、 com? OO 
101226129158 | | 
0 


_- 合 www.qq.com? 

一 一 一 一 一 一 > 

yb | 61135157.156 
WY A ~ 

北京 联通 用 户 北京 联通 本 地 DNS 


图 3 
不 过 这 个 机 制 并 非 完 美 ， 比 如 当 用 户 自 己 配 错 DNS 服 务 器 的 时 候 
就 可 能 出 问题 。 图 3 的 腾讯 GSLB 服 务 器 其 实 并 不 是 通过 用 户 的 地 址 来 


上 海 电 信用 户 


腾讯 GSLB 服 务 器 


判断 该 返回 什么 IP 的 ， 而 是 根据 DNS 服 务 器 的 地 址 来 判断 的 。 假 如 上 
海 电 信用 户 偏 偏 要 配 一 个 北京 联通 的 DNS 地 址 ， 那 它 发 送 DNS 查 询 
时 ， 束 是 由 北京 联通 转 给 GSLB 的 ， 因 此 会 解析 到 属于 北京 联通 的 IP 地 
址 。 由 于 中 国 的 跨 运 营 商 网 络 一 向 是 瓶 倾 ， 所 以 用 户 体 验 会 很 糟糕 。 
还 有 些 用 户 配 的 是 在 美国 的 DNS 服务 器 8.8.8.8， 那 莽 可 能 解析 到 一 个 位 
于 美国 的 IP 地 址 〈 启 用 了 谷歌 扩展 协议 的 客户 端 除外 ) ， 网 速 就 更 差 
了 。 根 据 公 众 号 “ 鹅 广 网 事 ” 的 说 法 ， 他 们 遭遇 的 GSLB 问 题 还 有 很 多 ， 
比如 动 持 什 么 的 ， 本 文 就 不 一 一 列举 了 。 

那 鹅 三 的 解决 方式 是 什么 呢 ? 就 是 本 文 开头 提 到 的 HttpDNS。 它 允 
许 手 机 上 的 App 直 接 查 询 腾 讯 自 家 的 HttpDNS 服 务 器 ， 因 此 能 根据 用 户 
的 地 址 来 判断 应 该 返回 什么 卫 ， 从 而 跳 过 传统 DNS 的 影响 。 换 句 话 
说 ， 就 是 腾讯 觉得 用 传统 DNS 不 靠 谱 ， 所 以 自己 做 了 一 套 解析 方式 ， 
只 不 过 这 套 方 式 是 走 HTTP 协 议 的 ， 图 4 演示 了 这 个 过 程 。 


回 


上 海 电信 用 户 


HttpDNS 服 务 器 


北京 联通 用 户 


图 4 

从 原理 上 看 ，HttpDNS 是 科学 的 ， 不 过 得 多 花 些 钱 去 部 署 。 根 据 
“ 鹅 三 网 事 * 的 宣传 ， 似 乎 在 内 部 已 经 推广 了 : 

“HttpDNS 已 在 腾讯 内 部 接 入 了 多 个 业务 ， 禾 盖 数 亿 用 户 ， 并 已 持 
续 稳定 运行 超过 一 年 时 间 。 而 接 入 了 HttpDNS 的 业务 在 用 户 访问 体验 方 
面 都 有 了 非常 大 的 提升 ..….…... 国 内 最 大 的 public DNS 服务 商 114DNS 在 受 
到 腾讯 DNS 的 局 发 下 ， 也 推出 了 HttpDNS 服 务 ..….” 

这 个 宣传 听 上 去 非常 吸引 人 “。 去 年 发 生 过 一 次 全 国 性 的 DNS 次 
痪 ， 当 时 故 矿 的 几 个 应 用 (比如 QQ 和 微 信 ) 都 能 正常 使 用 ， 似 乎 就 是 
一 个 有 力 的 伍 证 。 连 鹅 三 的 竞争 对 手 似乎 也 加 入 了 宣传 ， 比 如 淘宝 的 
官方 微 博 发 过 一 条 消息 ， 称 “手机 淘宝 使 用 专 为 移动 设计 的 方案 ”不 会 


受到 DNS 瘫 痪 的 影响 。 当 时 也 有 圈 内 牛人 出 来 解释 ， 说 这 意味 着 手 淘 
也 开始 用 上 HttpDNS 了 。 总 而 言 之， 如 果 你 对 技术 圈 的 八卦 消息 感 兴 
趣 ， 一 定 会 觉得 HttpDNS 已 经 快 颠覆 DNS 了 。 

事实 真 的 如 此 吗 ? 我 一 直 有 些 怀疑 ， 理 由 如 下 。 

:电脑 上 很 多 应 用 程序 也 依赖 DNS 解 析 ， 而 且 在 电脑 上 很 容易 配 错 
DNS 服 务 器 ， 理 论 上 出 问题 的 概率 更 大 ， 为 什么 就 不 部 署 HttpDNS? 而 
手机 上 的 DNS 地 址 一 般 是 运营 商 自动 分 配 的 ， 出 问题 的 概率 小 ， 为 什 
么 反而 要 部 署 ? 

:即便 运营 商 分 配 的 DNS 有 问题 ， 那 也 可 以 通过 行政 手段 来 解决 ， 


何必 要 为 此 大 动 干戈 呢 ? 
.国外 的 互联 网 公司 也 会 遇 到 这 类 问题 ， 为 什么 它们 就 没有 采用 
HttpDNS? 


传统 DNS 基 于 UDP 查 询 的 速度 很 快 ， 而 HttpDNS 肯 定 是 基于 TCP 
的 ， 那 还 会 浪费 3 次 握手 和 4 次 挥手 的 时 间 。 

HttpDNS 如 采 不 加 密 ， 那 也 很 容易 被 支持 ， 如 采 加 密 了 ， 解 析 效 
率 又 会 大 受 影响 。 

总 之 有 太 多 难以 解释 的 疑问 了 ， 我 越级 磨 就 越 想 看 看 HttpDNS 的 访 
山 真面目 。 为 了 解 开 这 个 访 题 ， 我 在 搭 好 手机 抓 包 环境 之 后 ， 束 设计 
了 一 系列 实验 来 寻找 这 个 传说 中 的 新 技术 。 

实验 1 

1. 启动 Wireshark 抓 包 。 

2， 登录 手机 淘宝 。 

3. 停止 抓 包 并 分 析 。 

Wireshark 截 屏 见 图 5。 这 个 结果 令 我 大 失 所 诅 ， 原 来 手 淘 老 老实 实 
地 用 传统 DNS 查 询 到 了 服务 器 d.taobaocdn.com 的 IP 地 址 ， 然 后 就 三 次 握 
手 了 。 也 就 是 说 ， 它 并 没有 用 到 HttpDNS 。 


o. Time Source Destination Protocol Info 


1 0.000000000 Android DNS DNS standard query Ox6123 A d.taobaocdn. com 

2 0.009048000 DNS Android DNS standard query response 0x6123 CNAME d.taobaocdn. com. 
3 0.010750000 Android d.taobaocdn. com TCP 45134~80 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PEF 
4 0.016174000 d.taobaocdn. com Android TCP 80-45134 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1¢ 
5 0.017097000 Android d.taobaocdn. com TCP 45134-80 [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSval=1205 


图 5 

那 淘宝 官方 微 博 宣 称 的 “ 专 为 移动 设计 的 方案 * 是 什么 呢 ? 我 又 做 
了 个 实验 。 

实验 2 

1， 登录 手机 淘宝 。 

2. 然后 改 意 把 手机 上 的 DNS 服 务 器 改 错 ， 发 现 手 淘 还 能 用 。 

3. 退出 手 淘 ， 再 次 登录 ， 就 再 也 登 不 上 去 了 。 

可 见 这 所 谓 的 方案 只 不 过 是 在 登录 之 后 缓存 了 P 而 已 ， 并 不 是 用 
HttpDNS 取 代 DNS。 既然 手 淘 不 行 ， 我 决定 在 手机 上 装 个 筷 三 的 QQ 试 
地 全 次 我 故意 从 一 开始 就 配 错 DNS 。 

实验 3 

1. 在 手机 上 配 个 无 效 的 DNS， 然 后 开始 Wireshark 抓 包 

2. 登录 于 机 QQ 。 

3. 停止 抓 包 并 分 析 。 

Wireshark 和 截图 如 图 6 所 示 。 手 机 发 了 几 个 传统 的 DNS 查询 都 没有 得 
到 响应 ， 然 后 竟然 就 和 卫 地 址 113.108.90.53 三 次 握手 了 。 这 个 IP 从 何 而 
来 ? 应 该 束 是 来 自 HttpDNS 了 吧 ? 然而 在 Wireshark 中 用 尽 各 种 Filter 和 
Find 都 找 不 到 相应 的 包 。 难 不 成 这 个 了 是 安装 QQ 时 就 存在 配置 文件 中 
的 ? 我 从 I 库 中 查 到 它 位 于 1500 公 里 外 的 深圳 市 ， 应 该 不 会 是 高 度 智 
能 的 HttpDNS 解 析出 来 的 。 


No. Time Source Destination Protocol Info 
231 41.944338000 Android wrong_DNS DNS standard query Oxf3cf A msfwifi.3g.qq.com 
232 41.944542000 Android Wrong_DNS DNS standard query Oxe9df A configsvr.msf.3g.qq.com 
233 42.463699000 Android wrong_DNS DNS standard query Ox3e39 A monitor.uu.qq.com 
237 45.945841000 Android Wrong_DNS DNS standard query Oxbb54 A strategy.beacon. qq. COm 
238 46.943161000 Android wrong_DNS DNS standard query Oxf403 A monitor.uu.qq.com 
239 46.969910000 Android 113.108.90.53 TCP 34777~8080 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 
240 47.010944000 113.108.90.53 Android TCP 8080-~34777 [SYN, ACK] seq=0 Ack=1 Win=5400 Len=0 MSS=1350 S/ 
241 47.012451000 Android 113.108.90.53 TCP 34777~8080 [ACK] Seq=1 Ack=1 Win=14720 Len=0 


图 6 


三 个 实验 结果 都 和 预想 的 不 同 ， 真 令 人 心情 复杂 ， 难 道 技 术 圈 的 
传闻 并 不 可 靠 ? 反正 时 间 都 化 了 这 么 多 了 ， 我 索性 再 做 一 个 实验 ， 彻 
底 捅 清楚 QQ 的 工作 方式 。 

实验 4 

1. 在 手机 上 配 一 个 正确 的 DNS， 然 后 开始 Wireshark 抓 包 

2. 登录 手机 QQ。 

3. 停止 抓 包 再 分 析 。 

Wireshark 截 图 如 图 7 所 示 。QQ 老 老实 实地 用 传统 DNS 查 到 IP， 然 
后 就 三 次 握手 了 。 可 见 它 首 选 的 就 是 传统 DNS， 只 有 当 DNS 查 询 失 
败 ， 它 才 直 接 用 (可 能 存在 配置 文件 里 的 ) IP 来 登录 ， 根 本 没有 用 到 


HttpDNS 。 

No, Time Source Destination Protocol Info 
10 0.978862000 Android DNS DNS standard query Oxf044 A msfwifi.3g.qq.com 
11 0.989012000 DNS Android DNS standard query response Oxf044 A 113.108.16.66 
12 0.990810000 Android msfwifi.3g.qq.com TCP 40188-8080 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
26 1.030616000 msfwifi.3g.qq.com Android TCP 8080-40188 [SYN, ACK] Seq=0 Ack=1 Win=5400 Len=( 
27 1.031460000 Android msfwifi.3g.qq.com TCP 40188-8080 [ACK] Seq=1 Ack=1 Win=14720 Len=0 


图 7 

一 系列 实验 做 下 来 ， 我 竟然 没有 找到 传说 中 的 HttpDNS。 牧 三 宣传 
的 “多 个 业务 ”究竟 指 的 是 哪些 ， 我 也 不 得 而 知 。 不 过 既然 连 QQ 和 手 淘 
都 没 在 用 ， 我 怀疑 世界 上 本 来 就 没 多 少 知 名 App 在 用 它 。 即 便 有 ， 我 也 
动力 再 去 寻找 了 人。 当然 做 了 这 些 实验 也 不 是 一 无 所 获 ， 人 至少 理 清 

儿 个 知名 App 在 域名 解析 上 的 行为 差异 。 

新浪 微 博 : 一 旦 出 现 DNS 问 题 就 不 能 用 ， 无 论 是 否 已 经 登录 ， 因 
为 它 不 缓存 IP。 详 细 实 验 过 程 请 看 前 一 篇 。 

:手机 淘宝 : 一 旦 出 现 DNS 问 题 束 无 法 登录 ， 但 是 登录 后 再 出 DNS 
问题 就 不 怕 了 ， 因 为 它 有 绥 存 IP。 

手机 QQ: | 因为 它 可 以 直接 用 (可 能 存在 
配置 文件 里 的 ) 了 P， 因 此 受 DNS 次 痪 的 影响 最 小 。 
注意 : 我 只 是 描述 了 当前 观察 到 的 现象 ， 并 不 是 说 某 个 App 比 其 他 的 更 先进 。 而 且 互联 网 
界 变化 很 快 ， 说 不 定 等 你 看 到 这 篇 文章 时 ， 这 些 App 的 行为 又 有 所 不 同 ， 甚 至 真 的 用 上 


HttpDNS 了 ， 到 时 候 抓 包 才 知道 。 

这 件 事 也 促使 我 重新 审视 技术 圈 的 信息 传播 。 有 上 段子 说 , “美国 研 
究 机 构 发 现 ， 人 们 很 容易 对 ‘美国 研究 机 构 发 现 ; 开 头 的 报道 信 以 为 
真 。” 同 样 地 ， 当 IT 大 广 慷 慨 地 分 享 一 项 技术 时 ， 当 圈 内 大 牛 热情 地 跟 
着 传播 时 ， 我 们 就 会 本 能 地 觉得 高 大 上 起 来 。 而 真实 情况 如 何 ， 却 只 
有 目 己 做 实验 才 知 道 。 小 马 过 河 ， 方 知 深 乒 。 


作为 中 国 网 民 ， 我 们 享有 学 习 网 络 知 识 的 天 然 优 势 ， 这 是 很 多 老 
外 一 幸子 部 不 到 睹 望 的 。 还 记得 刚 学 会 上 网 的 时 候 ， 某 知名 搜索 网 站 
突然 束 连 不 上 了 ， 有 位 学 长 说 这 古 域 名 被 封 ， 直 接连 IP 束 可 以 了 ， 还 
帮 有 我 修改 了 hosts 文 件 。 于 二 我 沿 看 这 个 方 问 研究， 很 快 孢 理解 了 DNS 
协议 。 在 实践 中 学 到 的 本 领 ， 比 捧 着 课本 背诵 的 不 知道 高 到 哪里 去 。 

又 过 了 一 阵 ， 竟 然 连 卫 都 连 不 上 了 。 我 在 探索 过 程 中 ， 又 学 会 
HTTP 代理 和 VPN 等 科学 上 网 技术 。 束 这 样 ， 十 几 年 下 来 号 经 百 战 ， 不 
知 不 党 中 掌握 了 很 多 网 络 技术 ， 每 天 都 能 到 外 网 和 同行 们 谈笑风生 。 
现在 回忆 起 来 ， 我 的 知识 真 没 多 少 是 刻意 去 学 的 ， 而 是 在 和 网 络 问题 
斗争 时 被 动 学 会 的 。 被 虐 人 了 还 得 了 斯 德 哥 尔 摩 综合 证 ， 去 年 到 国外 
出 过 了 一 个 月 ， 便 觉得 食 不 知味 ， 因 为 根本 找 不 到 学 习 的 机 会 。 回 到 
国内 赶紧 打开 浏览 器 ，Duang 一 一 立即 弹出 运营 商 推送 的 广告 。 还 是 那 
个 熟悉 的 味道 ， 回 家 的 温馨 顿时 请 上 心头 。 

本 文 要 讲述 的 也 是 一 个 顺 有 中 国 特色 的 网 络 技术 ， 其 实 很 多 人 都 
遇 到 过 ， 但 没有 去 深究 。 最 早 同 我 反馈 的 钙 一 位 细心 的 网 友 ， 他 在 打 
开 www.17g.com 这 个 游戏 网 站 时 ， 有 一 定 概 率 会 加 载 出 其 他 网 站 的 游 
戏 ， 比 如 xunlei 的 。 他 觉得 很 好 奇 ， 便 采取 了 一 些 措 施 来 排查 。 


1. 一 开始 怀疑 是 电脑 中 毒 ， 于 是 在 同 网 络 下 的 其 他 电脑 上 测试 ， 
症状 还 是 一 样 。 

2. 其 他 地 区 的 网 友 (包括 我 ， 打 开 这 个 网 站 时 没有 发 现 相同 问 
题 。 

3， 他 怀疑 是 当地 运营 商 〈 哪 家 运营 商 我 就 不 说 了 ) 搞 的 网 ， 于 是 
换 了 个 宽带 ， 果 然 就 没 问 题 了 。 

这 位 网 友 很 生气 ， 想 知道 运营 商 究竟 对 他 的 网 络 做 了 什么 手脚 ， 
所 以 抓 了 个 出 问题 时 的 包 来 找 我 。 我 网 开始 以 为 很 简单 ， 肯 定 是 运营 
商 的 DNS 劫持 ， 即 故意 在 收 到 DNS 查询 时 回应 一 个 假 的 了 地 址 ， 从 而 
导致 客户 端 加 载 错 误 的 广告 页 面 。 于 是 我 打开 网 络 包 ， 用 dns 作 了 过 
滤 ， 发 现 www.17g.com 被 解析 到 了 IP 地 址 123.125.29.243 〈 它 还 有 一 个 
别名 叫 w3.dpool.sina.com.cn， 见 图 1) 。 可 是 经 过 进一步 测试 验证 ， 发 
现 这 个 了 地 址 竟然 是 对 的 ， 并 没有 被 劫持 。 


| Filter | dns | Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
1 0.000000000 Client DNS_Sserver DNS standard query Oxcdd8 A www.17g.c 
2 0.001818000 DNS_server Client DNS standard query response Oxcdd8 EE w3. dpoo1.sina.com.cn A 123.125.29.243 


图 1 

既然 不 是 DNS 劫持 ， 那 又 是 什么 原因 导致 的 呢 ? 可 展 这 位 网 友 抓 
包 的 时 候 电 脑 上 开 了 太 多 应 用 ， 所 以 干扰 包 很 多 ， 无 法 采用 暴力 方式 
来 分 析 (就 是 指 不 过 滤 ， 用 肉眼 把 所 有 包 都 一 一 看 过 的 分 析 方 式 ) 
如 果 用 “ip.addr eq 123.125.29.243” 过 滤 则 得 到 图 2 的 结果 ， 似 乎 平淡 无 
奇 ， 只 是 显示 有 些 包 乱 序 了 ， 但 不 知道 这 意味 着 什么 。 后 来 我 才 知 道 
这 束 是 线索 之 一 ， 具 体 原 因 后 面 会 讲 到 。 


Filter | ip.addr eq 123.125.29.243 [=] Eepression.. Clear Apply Save 


No. Time Source Destination Protocol Info 

3 2.466565000 Client w3. dpoo1.sina. com.cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS= 
4 2.486628000 w3.dpoo1.sina.com. cn Client TCP 80-58578 [SYN, ACK] Seq=0 Ack=l Win=14600 Len=0 | 
5 2.486716000 Client w3. dpoo1.sina.com.cn TCP 58578-80 [ACK] Seq=1 Ack=l Win=65700 Len=0 

6 2.487789000 Client w3. dpoo1.sina. com.cn TCP [TCP segment of a reassembled PDU] 

7 2.487807000 Client w3. dpoo1.sina.com.cn HTTP GET /game?game_id=1 HTTP/1.1 

8 2.491232000 w3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=1461 Win=2102400 Len=0 
9 2.491663000 w3.dpoo1.sina. com.cn Client TCP 80-~58578 [PSH, ACK] Seq=1 Ack=1461 Win=2102400 L 
10 2.492354000 Client w3. dpoo1.sina. com.cn TCP 58578-80 [FIN, ACK] Seq=1595 Ack=558 Win=65140 L 
11 2.507937000 w3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=1595 Win=17536 Len=0 

12 2.508130000 w3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=1 Win=14720 Len=0 SLE=1. 
13 2.508153000 Client w3. dpoo1. sina. com. cn TCP [TCP Dup ACK 10#1] 58578-80 [ACK] Seq=1596 Ack=5 
26 2.739402000 w3.dpoo1.sina.com.cn Client TCP pr os cement not captured]] 80-58578 [Ac 
27 2.739403000 w3.dpoo1.sina. com. cn Client TCP 80-58578 [FIN, ACK] Seq=4381 Ack=1595 Win=17536 
28 2.739439000 Client w3. dpoo1.sina.com.cn TCP [TCP Dup ACK 10#2] 58578-80 [ACK] Seq=1596 Ack=5 
29 2.739474000 Client w3. dpoo1.sina. com. cn TCP [TCP Dup ACK 10#3] 58578-80 [ACK] Seq=1596 Ack=5 
30 2.739608000 w3.dpool.sina.com.cn Client TCP [TCP out-of-order] [TCP segment of a reassembled 
31 2.739637000 Client w3. dpoo1.sina. com. cn TCP TCP_ACKed unseen segment] 58578-~80 [RST, ACK] S 
32 2.739970000 w3.dpoo1.sina.com.cn Client TCP [TCP segment of a reassembled 


由 于 这 有 是 我 第 一 次 分 析 支持 包 ， 所 以 不 得 要 领 ， 当 晚 分 析 到 竣 晨 
都 没有 和 弄 明 日 。 第 二 天 早上 只 好 到 技术 群 求援 了 ， 一 位 在 运营 商工 作 
的 朋友 给 我 科普 了 HTTP 劫 持 的 几 种 方式 。 其 中 有 一 种 引起 了 我 的 注 
意 ， 其 大 概 工作 方式 如 图 3 所 示 ， 实 线 箭 头 表 示 正 常 的 网 络 包 ， 虚 线 箭 
头 才 示 运 各 商 做 的 手脚 。 


分 光 器 假 Web 服 务 器 


g9 真 HTTP 响 应 


用 户 路 由 器 路 由 器 真 Web 服 务 器 
图 3 

注意 : 这 只 是 简单 的 示意 图 ， 不 完全 等 同 于 真实 过 程 。 
在 正常 情况 下 ， 用 户 发 出 的 HTTP 请 求 ( 即 图 中 的 Q)) 经 过 层 层 路 
由 才能 到 达 真 实 的 Web 服务 器 ， 然 后 真实 的 HTTP 响 应 ( 即 图 中 的 @)) 
又 经 过 层 层 路 由 才能 回 到 用 户 端 。 而 在 做 了 手脚 的 网 络 中 ， 运 营 商 可 


上 


以 在 路 由 硼 上 复制 HTTP 请 求 ， 再 交 给 假 的 Web 有 上 服务 右 。 然 后 赶 在 真 
的 HITP 响 应 之 前 ， 把 假 的 HITTP 响 应 〈 即 图 中 的 @) 送 达 用 户 。 这 
抢先 应 答 会 导致 用 户 在 收 到 真实 的 HITP 啊 应 时 ， 以 为 是 无 效 包 而 
弃 。 


站 他 将 


根据 这 个 工作 原理 ， 我 们 能 否 推测 出 假 的 HITP 响 应 有 什么 特征 
呢 ? 如 果 能 ， 那 就 能 据 此 过 滤 出 关键 包 了 。 我 首先 考虑 到 的 是 网 络 层 
的 特征 : 因为 假 Web 服 务 器 是 抢先 应 答 的 ， 所 以 它 发 出 的 包 到 达 用 户 
时 ，TIL (Time to Live) 可 能 和 真实 的 包 不 一 样 。 那 要 怎么 知道 真实 
的 TIL 应 该 是 多 少 呢 ? 考虑 到 3 次 握手 发 生 在 HITP 动 持 之 前 ， 所 以 我 们 
可 以 假定 参与 3 次 握手 的 那 台 服务 器 是 真 的 ， 从 图 4 可 见 其 TTL 为 54。 


Filter: | ip.addr eq123.125.29.243 |~] Expression.. Clear Apply Save 

No,. Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1.sina.com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 ， 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80-58578 [SYN, ACK] Seq=0 Ack=1 Win=: 
5 2.486716000 Client w3. dpoo1. sina. com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 


中 


Fragment offset: 0 


Protocol: TCP (6) 


图 4 

接 下 来 就 要 动手 过 滤 出 假 的 包 了 。 根 据 其 源 地 址 同样 为 
123.125.29.243， 但 TIL 不 等 于 54 的 特征 ， 我 用 “(ip.srceq 123.125.29.243) 
久 必 1 (ip.ttl==54)” 过 小， 得 到 图 5 的 两 个 包 ， 即 8 号 包 和 9 号 包 。 看 看 右 
下 角 显 示 了 什么 信息 ?这 不 正 是 我 要 寻找 的 假 页 面 


“src=http:Wjump.niu.xunlei.com:8080/6zma2a2 吗 ? 


Source 


Fikter: | (ipsrc eq 123.125.29.243) && I(ip.ttl == 54) 


INo. Time 
8 2.491232000 w3.dpool.sina.com.cn Client TCP 
9 2.491663000 w3.dpool.sina.com.cn Client TCP 


[<] Expression.. Clear Apply Save 


Destination Protocol Info 


80-58578 [ACK] Seq=1 ACk=1461 Win=2102400 Len=0 
80-58578 [PSH, ACK] Seq=1 Ack=1461 Win=2102400 | 


但) 


这 个 发 现 令 我 信心 大 增 ， 有 种 拨 云 见 日 的 感觉 


图 5 
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。 再 往 下 看 几 个 


果然 发 现 了 和 jump.niu.xunlei.com 的 新 连接 。 接 着 这 个 连接 又 把 页 
面 跳 转 到 了 “http://niu.xunlei.com/actives/welcome1426......” 上 〈 见 图 


\ \ = sh 
6) 。 跳 来 跳 去 地 非常 难以 追寻 。 
Fitter | | Expression... Clear Apply Save 
No. Time Source Destination Protocol Info 
14 2.536747000 Client jump.niu.xunlei.com TCP 58582-8080 [SYN] Seq=0 Win=8192 L 
15 2.557662000 jump.niu.xunlei.com Client TCP 8080-~58582 [SYN, ACK] Seq=0 Ack=1 
16 2.557712000 Client jump.niu.xunlei.com TCP 58582-8080 [ACK] Seq=1 Ack=1 Win= 
17 2.558448000 Client jump.niu.xunlei.com HTTP GET /6zma2a HTTP/1.1 
18 2.579387000 jump.niu.xunlei.com Client TCP 8080~*58582 [ACK] Seq=1 Ack=1134 W 
19 2.580233000 jump.niu.xunlei.com Client HTTP HTTP/1.1 301 Moved Permanently ( 
20 2.582205000 Client DNS_Server DNS standard query Ox3851 A ct.niu.x 
21 2.583707000 DNS_server Client DNS standard query response Ox3851 CC 
4 四 


图 6 

再 后 面 的 包 就 没 必 要 分 析 了 ， 以 上 证 据 已 经 足以 向 工信部 投诉 。 
据说 投诉 后 运营 商 解决 起 问题 来 还 挺 碍 快 的 ， 百 度 曾 经 上 诉 某 运 营 商 
的 支持 案件 也 获 赔 了 。 商场 上 的 黑暗 故事 ， 束 不 在 本 书 里 展开 讨论 
了 ， 我 们 还 是 继续 关注 技术 问题 吧 。 

在 这 个 案例 中 ， 万 一 真 假 网 络 包 的 TTL 恰好 一 样 ， 还 有 什么 办 法 可 
以 找 出 假 的 包 吗 ? 仔细 想 想 还 是 有 的 。 比 如 服务 器 每 发 送 一 个 包 ， 就 
会 对 其 网 络 层 的 Identification 作 加 1 递增 。 由 于 4 号 包 的 Identification 为 
4078 〈 见 图 7) ， 那 它 的 下 一 个 包 ， 也 就 是 8 号 包 的 Identification 就 大 概 
是 4079 了 (或 者 略 大 一 些 ) 。 可 是 从 图 8 可 见 ， 它 的 Identification 一 下 
子路 到 了 55872， 这 也 是 一 个 被 支持 的 明显 的 特征 。 


Fikter: | [>| epression.. Clear Apply Save 
No. Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1. sina.com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSS=146! 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80--58578 [SYN, ACK] Seq=0 Ack=1 Win=14600 [ 
5 2.486716000 Client Ww3. dpoo1.sina. com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 Len=0 
站 Ml 
Identification: OxOfee (4078 


图 7 
Filter: -| Expression... Clear Apply Save 
No， Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1.sina.com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSS=1. 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80~58578 [SYN, ACK] Seq=0 Ack=l Win=14600 
5 2.486716000 Client w3. dpoo1.sina. com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 Len= 
6 2.487789000 Client w3. dpoo1. sina. com. cn TCP [TCP segment of a reassembled PDU] 
7 2.487807000 Client w3. dpoo1. sina. com. cn HTTP GET /game?game_id=1 HTTP/1.1 
8 2.491232000 w3.dpool.sina.com.cn Client TCP 80-+58578 [ACK] Seq=1 Ack=1461 Win=2102400 
Mm 
Identification: Oxda40 (55872 
图 8 


那 万 一 运营 商 技 术 高 超 ， 把 TTL 和 Identification 都 给 对 上 号 了 ， 我 
们 还 有 什么 特征 可 以 找 吗 ? 还 是 有 的 ! 刚刚 介绍 的 两 个 特征 都 在 网 络 
层 ， 接 下 来 我 们 可 以 到 TCP 层 找 找 。 在 图 5 可 以 看 到 8 号 和 9 号 这 两 个 假 
冒 的 包 都 声明 了 “win=2102400”， 表 示 服 务 器 的 接收 窗口 是 2102400 字 
节 。 对 比 一 下 其 他 网 络 包 ， 你 会 发 现 这 个 数字 大 得 出 奇 。 为 什么 会 这 
样 呢 ? 这 是 因为 真正 的 Web 服务 器 在 和 客户 端 建立 3 次 握手 时 ， 约 好 了 
它 所 声明 的 接收 窗口 要 乘 以 128 ( 见 图 9) 才 是 真正 的 窗口 大 小 。 假 的 


那 台 服务 器 不 知道 这 个 约定 ， 所 以 直接 把 真正 的 窗口 值 (win=16425) 
发 出 来 ， 被 这 么 一 乘 就 变 成 了 16425x128=2102400 字 节 ， 大 得 夸张 。 


No, Time Source Destination Protocol Info 


3 2.466565000 Client w3. dpoo1. sina. com. cn TCP 58578~80 [SYN] Seq=0 Win=8192 Len=0 MSS=14 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80-~58578 [SYN, ACK] seq=0 Ack=l Win=14600 


5 2.486716000 Client w3. dpoo1.sina.com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 Len=( 


日 Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Op 
H Maximum segment size: 1460 bytes 
田 No-Operation (NOP) 
习 No-Operation (NOP) 
TCP SACK Permitted Option: True 
习 NO-Operation (NOP) 
由 Window scale: 7 (multip 


图 9 

这 个 特征 在 本 案例 中 非常 明显 ， 但 不 是 每 个 TCP 连 接 被 动 持 后 都 会 
表现 出 来 的 。 假 如 3 次 握手 时 没有 声明 图 9 所 示 的 Window Scale 值 ， 那 就 
无 此 特征 了 。 

其 实 我 在 一 开始 还 提 到 了 男 一 个 现象 ， 即 图 2 中 Wireshark 提 示 的 

[TCP Previous segment not captured| 和 [TCP Out-of-Order| ， 意 味 着 
存在 乱 序 。 为 什么 会 有 这 些 提示 呢 ? 这 是 因为 假 服务 器 伪造 的 包 抢先 
到 达 ， 增 加 了 Seq 号 ， 因 此 等 到 真 服 务 右 发 出 的 包 到 达 时 ，Seq 号 已 经 
对 不 上 了 “。Wireshark 还 没有 智能 到 能 判断 真 假 包 的 程度 ， 只 能 根据 Seq 
号 的 大 小 提示 乱 序 了 。 

总 而 言 之 ， 在 理解 了 劫持 原理 之 后 ， 我 们 便 能 推理 出 假 包 的 特 
征 ， 然 后 再 根据 这 些 特征 过 滤 出 关键 包 。 但 不 是 所 有 特征 都 能 在 每 次 
动 持 中 体现 出 来 的 ， 比 如 接收 窗口 的 大 小 就 很 可 能 是 正常 的 ， 所 以 一 
定 要 逐 层 认真 分 析 。 这 还 只 是 众多 劫持 方式 中 的 一 种 ， 如 果 采 用 了 其 
他 方式 ， 那 么 在 包 里 看 到 的 现象 又 会 有 所 不 同 。 等 我 下 次 遇 到 了 ， 再 
写 一 篇 跟 大 家 分 享 。 


一 个 协议 的 进化 


互联 网 行业 日 新 月 异 ， 几 年 前 估计 连 马 云 都 预想 不 到 今天 的 网 络 
规模 。 从 打车 、 订 和 餐 、 抢 购 手 机 到 付款 理财 ， 几 乎 无 孔 不 入 。 与 之 不 
相称 的 是 ， 互 联网 所 依赖 的 基础 协议 一 一 HTTP 却 一 直 没 有 更 新 。 知 道 
现在 最 通用 的 HTTP 1.1 是 什么 时 候 出 现 的 吗 ?20 世 纪 末 ! 那 时 候 我 还 
是 林家 庄 跑 得 最 快 的 少年 ， 现 在 下 个 楼 梯 都 能 感觉 肚子 上 的 脂肪 在 跳 
跃 。 

那 是 什么 使 得 HTTP 1.1 青 春 永 驻 呢 ? 是 因为 它 的 设计 特别 有 前 瞻 
性 吗 ? 可 惜 答 案 是 否定 的 。 当 今 网 络 的 两 个 特征 ， 导 致 HTTP 1.1 已 经 
成 为 性 能 瓶 代 [21 

:现在 网 络 的 带 宽 比 20 世 纪 大 得 多 ， 家 性 带宽 普 裔 在 10 兆 以 上 ， 有 

些 运 营 商 甚 至 提供 200 兆 的 家 庭 套餐 。 

.每 个 页 面 的 内 容 远 比 20 世 纪 的 丰富 ， 比 如 包含 了 更 多 小 图 片 。 类 
似 www.qq.com 这 样 还 不 算 炫 目的 网 站 ， 光 打开 首页 就 能 触发 一 百 多 个 
GET 请 求 ， 但 每 个 GET 的 数据 量 都 不 大 。 

这 两 个 特征 和 HTTP 1.1 有 什么 冲突 呢 ? 我 们 先 从 一 个 简单 的 例子 
开始 说 起 。 图 1 显示 的 是 一 个 典型 的 网 页 打开 过 程 ， 容 户 端 人 
建立 了 一 个 TCP 连 接 ， 然 后 从 服务 器 上 依次 GETT 了 三 个 资源 ， 每 个 的 数 
据 量 都 很 小 ， Ca 4-6，7-9 。 


3 
3 0.078748000 server Client i HTTP/ /1. 1 200 OK es /htm1) 

4 0.107910000 client server HTTP GET /qhome/uinterest?num=4&callback=contentInit&random=0.260833 
6 

9 


0.151834000 server Client HTTP HTTP/1.1 200 OK (text/html) 
7 0.179456000 Client server HTTP GET /newalgorithm/groupnews?callback=entCallback&channel=ent&ra 
0.225205000 Sserver Client HTTP HTTP/1.1 200 OK (text/htm]l) 


图 1 

从 这 个 包 里 面 可 以 看 出 不 少 问 题 。 

1. 客户 端 不 是 多 个 GET 请 求 一 起 发 出 的 ， 而 是 先 发 出 一 个 请 
等 收 到 啊 应 之 后 才 发 出 下 一 个 请 求 。 这 样 假如 前 一 个 操作 发 生 了 丢 
包 ， 就 会 直接 影响 到 后 续 的 操作 ， 成 为 “线头 阻塞 ”( Head of Line 
[IHOL| Blocking) 。 


2. 即使 没有 丢 包 ， 每 个 GET 至 少 也 要 耗费 一 个 RTT (往返 时 
间 ) 。 因 此 采用 这 种 非 并 发 的 方式 时 ， 上 百 个 GET 所 耗费 的 时 间 总 量 
束 非 常 可 观 。 

3. 这 种 工作 方式 导致 同时 发 出 的 包 数 太 少 ， 所 以 TCP 窗 口 再 大 也 
派 不 上 用 场 。 这 束 相 当 于 带 蜗 被 浪费 了 ， 家 里 办 个 200M 带 宽 和 10M 带 
宽 的 上 网 体验 差不多 。 想 象 一 下 六 车 道 马 路 上 总 共 跑 着 3 辆 车 ， 你 就 能 
理解 这 种 浪费 了 。 

4. 还 有 一 个 副作用 ， 就 是 包 数 太 少 会 竣 不 起 触发 快速 重 传 所 必需 
的 3 个 Dup Ack， 因 此 一 丢 包 就 只 能 等 得 超时 重 传 ， 效 率 大 打折 扣 。 

图 1 演示 的 还 只 是 明文 传输 的 情况 ， 如 采 要 加 密 传输 还 会 出 现 更 严 
重 的 延迟 。 图 2 是 一 个 HTTP 1.1 加 和 密 传 输 过 程 ， 由 于 HTTP 协 议 本 身 是 
明文 传输 的 ， 所 以 用 到 了 TLS 来 加 密 。 


Neo. Time Source Destination Protocol Info 
0.000000000 Client server TCP 57422-443 [SYN] Seq=2414288222 Win=8192 Len=0 MSS=1460 WS=4 SACK_PER 
0.088498000 Server Client TCP 443-~57422 [SYN, ACK] Seq=2346460516 Ack=2414288223 Win=65535 Len=0 M 
0.088617000 Client Server TCP 57422-443 [ACK] seq=2414288223 Ack=2346460517 Win=66364 Len=0 


0.091404000 client server TLSVv1.2 Client Hello 
0.178971000 Sserver Client TLSVv1.2 server Hello 


0.179328000 Sserver Client TCP 443-57422 [ACK] Seq=2346460517 Ack=2414288447 Win=6592 Len=0 
0.179360000 Client Server TCP 57422-443 [ACK] Seq=2414288447 Ack=2346461885 Win=64996 Len=0 
0.179674000 Server Client TLSv1.2 Continuation Data 

0.179712000 Client Server TCP 57422-443 [ACK] Seq=2414288447 Ack=2346461885 Win=64996 Len=0 SLE=23 
0.180481000 Server Client TLSv1.2 Continuation Data 

0.180531000 Client Server TCP 57422-443 [ACK] Seq=2414288447 Ack=2346464621 Win=66364 Len=0 


0.180678000 Server Client TLSv1.2 Continuation Data 

0.180789000 server Client TLSv1.2 Continuation Data 

0.180822000 Client Server TCP 57422-~443 [ACK] Seq=2414288447 Ack=2346466709 Win=66364 Len=0 
0.183432000 Client Server TLSVv1.2 Client Key Exchange, Change Cipher spec, Encrypted Handshake Message 
0.272740000 Sserver Client TLSVv1.2 Change Cipher spec, Encrypted Handshake Message 


0.473554000 Client Server TCP 57422-443 [ACK] Seq=2414288789 Ack=2346466784 Win=66288 Len=0 
0. 520483000 Server Client  TLSv1.2 ”Change Cipher spec, Encrypted Handshake Message 
0. 520554000 Client Server TCP 57422-443 [ACK] Seq=2414288789 Ack=2346466784 Win=66288 Len=0 SLE=23 


0.644898000 Client Server TLSVv1.2 Application Data 
0.734305000 Server Client TLSv1.2 Application Data 
0.734499000 server Client TLSv1l.2 Application Data 


图 2 
这 个 过 程 可 以 分 解 成 下 面 三 步 。 
1， 前 3 个 包 是 三 次 握手 过 程 ， 完 成 时 刻 是 0.0886 秒 。 
2， 接 下 来 的 4~19 号 包 是 TLS 握 手 过程， 完成 时 刻 是 0.5206 秒 。 
3. 20~22 号 包 是 真正 的 HTTP 传 输 过 程 ， 完 成 时 刻 是 0.7345 秒 。 
不 难看 出 ， 真 正 传输 有 效 数 据 的 是 第 三 步 ， 而 它 所 耗费 的 时 间 在 
整个 连接 中 的 比例 却 并 不 高 ， 大 多 时 间 是 被 前 两 步 用 掉 了 。 最 近 有 人 


在 倡导 所 有 网 站 都 加 密 ， 妇 怕 没有 意识 到 这 样 做 会 给 网 速 带 来 多 少 影 
啊 。 

既然 单个 连接 不 能 并 行 发 送 HTTP 请 求 ， 那 能 不 能 同时 建立 很 多 个 
连接 呢 ? 也 不 可 以 的 ,定义 了 HTTP 1.1 的 RFC 2616 明 确 把 最 大 连接 数 
限制 为 2 个 ， 原 文 如 下 : 

Clients that use persistent connections SHOULD limit the number of 
simultaneous connections that they maintain to a given server.A single-user 
client SHOULD NOT maintain more than 2 connections with any server. 

(使 用 长 连接 的 客户 端 应 当 限 制 和 某 一 台 服 务 句 的 同时 连接 数 。 单 用 
户 客户 端 不 能 和 任意 一 台 服 务 器 同时 保持 两 个 以 上 的 连接 。) 

综合 以 上 分 析 ， 我 们 可 以 得 到 一 个 结论 ， 即 HTTP 协 议 所 导致 的 网 
络 延 迟 才 是 影响 上 网 体 难 的 主要 因素 ， 而 不 是 市 宽 。 那 有 没有 改进 的 
办 法 呢 ? 的 确 有 一 些 优化 措施 ， 比 如 大 多 数 网 站 会 让 客户 端 与 多 人 台 服 
务 器 建立 并 发 的 TCP 连 接 。 图 3 是 我 在 打开 国外 某 购 物 网 站 时 的 HTTP 
包 ， 看 上 去 似乎 高 效 了 很 多 ， 至 少 可 以 向 多 台 服 务 妖 并 行 发 送 GET 
了 。 不 过 这 个 方案 也 不 完美 ， 因 为 每 个 新 建 的 TCP 连 接 都 会 处 于 慢 局 动 
状态 中 ， 传 输 效 率 很 低 。 而 过 了 慢 局 动 阶段 ， 速 度 终 于 变 快 了 ， 数 据 
却 已 经 传 完了 。 再 说 也 不 是 每 个 网 站 都 愿意 承担 多 台 服 务 器 的 成 本 。 


Filter | http | ~] Expression.. Clear Apply Save 


No. Time Source Destination Protocol Info 
289 5.345647000 Client server_3 HTTP GET /sportscheck/shop-de/s?home.homepage&ns__t=142797990! 
290 5.346611000 Client server_4 HTTP GET /cl1/1353134333236323131303.js HTTP/1.1 
292 5.360960000 Client server_5 HTTP GET /event?a=2150&v=3.1.0&p0=e%3Dexd%26ci%3D%26site_type: 
293 5.368956000 Client server_6 HTTP GET /json/2011-03-01/applications/mediaslot/0799C5544454; 
297 5.580102000 server_3 Client HTTP HTTP/1.1 200 OK (GIF89a) 


302 5.643010000 server_6 Client HTTP HTTP/1.1 200 OK (application/javascript) 
314 5.759077000 server_4 Client HTTP HTTP/1.1 200 OK (application/javascript) 
图 3 


还 有 一 个 优化 技术 叫 Pipelining， 可 惜 它 也 受到 一 些 限 制 ， 比 如 代 
理 服 务 需 不 文 持 等 。 那 有 没有 办 法 可 以 彻 确 地 解决 这 些 问题 呢 ? 我 脑 
洞 大 开 地 想象 一 下 ， 也 许 符合 以 下 需求 的 协议 才 可 以 : 

- 它 不 需要 三 次 握手 和 加 密 握 手 ， 能 够 节省 多 个 往返 时 间 ; 


' 它 没有 慢 局 动 过 程 ， 所 以 不 会 一 开始 束 传 得 很 慢 ; 

它 能 并 行 发 送 请 求 和 响应 ， 即 支持 “多 路 复 用 ” (Multiplexing) 。 

也 就 是 说 ， 当 前 的 一 个 HTTP 连 接 和 理想 中 的 差距 大 概 如 图 4 所 
示 。 同 样 古 3 个 操作 ， 理 想 中 的 模型 处 理 起 来 会 快 得 多 。 


当前 的 一 个 HTTP 连 接 理想 中 的 一 个 HTTP 连 接 
请 求 
握手 
间 
响应 
请 求 响应 
响应 
响应 
请 求 
响应 
请 求 
响应 
客户 端 服务 器 客户 端 服务 器 
图 4 


要 完美 实现 这 些 需 求 ， 泡 怕 现 有 的 HTTP 和 TCP 机 制 都 要 被 抛弃 ， 
得 重新 设计 一 套 全 新 的 协议 才 行 。 这 在 技术 上 也 不 是 没有 可 能 ， 说 不 
定 Google 和 Microsoft 之 类 的 公司 就 有 这 样 的 实力 ， 但 是 在 商业 上 完全 
不 可 行 一 一 在 当前 如 此 庞大 的 网 络 规模 面前 ， 谁 也 没有 实力 去 推动 所 
有 了 网站、 运营 商 和 客户 端 做 出 改变 。 不 要 说 TCP 了 ， 就 连 HTTP 层 的 升 
级 都 会 遇 到 不 少 阻 力 ， 因 此 只 能 采用 加 下 兼容 、 逐 步 改 进 的 办 法 。 

近 几 年 束 有 一 些 业内 先锋 尝试 了 不 同 的 解决 方案 。 其 中 最 出 色 的 
是 Google 推 出 的 SPDY 协 议 ， 它 只 是 在 HTTP 和 TCP 之 间 增 加 了 一 层 ， 从 
而 支持 多 路 复 用 等 功能 ( 即 在 一 个 TCP 连 接 里 并 行 处 理 多 个 HTTP 请 
求 ) ， 很 容易 得 到 现 有 网 站 和 客户 端的 支持 。 目 前 儿 乎 所 有 主流 浏览 
铬 都 文 持 SPDY， 比 如 在 Chrome 上 可 以 通过 “chrome://flags” 局 用 它 ， 如 
图 5 底部 所 示 。 国 外 的 主流 网 站 也 都 支持 SPDY， 比 如 Facebook、 


Wordpress、YouTube 和 Twitter 等 ， 可 惜 这 些 网 站 我 们 都 没有 条 件 测 试 。 
SPDY 的 多 路 复 用 解决 了 本 文 开 头 提 到 的 不 少 问 题 ， 比 如 市 宽 施 展 不 
开 、 丢 包 时 难以 触发 快速 重 传 等 。 经 过 几 年 的 实验 ，SPDY 终 于 在 2015 
年 “进化 ”到 HTTP 2.0。 


y 4% chrome:/flags 


各- 时 [1 chrome:y fags 


实验 性 QUIC 协议 。 Mac Windows, Linux, Chrome O35, Android 
局 用 实验 性 QUIC 协议 支持 。 #enable-quic 
已 启用 : 明 


UN 


a2 —— mp 一 一 


1s> | 业 i FP 一 ， 


现在 〈《2015 年 5 月 份 ) HITP 2.0 的 RFC 还 没有 出 来 。 不 过 在 其 草稿 
中 ， 已 经 明确 表示 “An HTTP/2.0 connection is an application level 
protocol running on top of a TCP connection”。 只 要 它 还 是 基于 TCP 的 ， 
区 还 有 改进 的 空间 ， ee 

怎么 改进 昵 ? 如 果 你 观察 足够 仔细 ， 还 会 在 图 5 中 看 到 一 个 “实验 性 

OE i 通信 ， 而 且 是 用 在 
HTTP 上 。 

QUIC 是 Quick UDP Internet Connections 的 简称 ， 旨 在 消除 网 页 应 用 
的 延迟 。 由 于 它 本 质 上 是 UDP， 所 以 不 需要 握手 也 没有 慢 局 动 过 程 ， 
技术 上 的 确 有 优势 。 目 前 只 有 Google 的 网 站 文 持 QUIC， 因 为 某 些 原 
因 ， 中 国 技术 人 员 还 没有 条 件 抓 包 来 学 习 〈 用 VPN 也 不 行 ) 。 我 委托 
一 位 印度 同行 抓 了 一 个 很 简单 的 包 ， 从 图 6 的 Seq 号 大 致 可 以 看 到 它 是 
并 发 传输 的 。 


No,. Time Source Destination Protocol Info 
18 5.062888000 Cclient server QUIC CID: 11989733321912874687, Seq: 1 
19 5.068569000 Client server QUIC CID: 11989733321912874687, Seq: 2 
20 5.070567000 server Client QUIC CID: 11989733321912874687, Seq: 1 
21 5.079090000 client server QUIC CID: 11989733321912874687, Seq: 3 
22 5.083972000 server Client QUIC CID: 11989733321912874687,， Seq: 2 
23 5.103229000 server Client QUIC CID: 11989733321912874687,，, Seq: 3 
24 5.109300000 client Server QUIC CID: 11989733321912874687, Seq: 4 
25 5.140611000 server Client QUIC CID: 11989733321912874687, Seq: 4 
26 5.211370000 client server QUIC CID: 11989733321912874687, Seq: 5 
32 5.460549000 Client server QUIC CID: 11989733321912874687, Seq: 6 
33 5.496031000 Sserver Client QUIC CID: 11989733321912874687, Seq: 5 
34 5.555704000 server Client QUIC CID: 11989733321912874687, Seq: 6 


图 6 

目前 QUIC 还 没有 流行 开 来 ， 但 Google 已 经 发 布 了 不 少 文档 。 说 来 
有 趣 ， 我 下 载 该 文档 时 ， 发 现 其 推荐 语 是 “如 果 你 需要 一 些 材 料 来 帮助 
睡眠 ， 可 以 看 看 这 些 文档 。” 让 人 哭笑不得 。 打 开 来 的 第 一 句 话 又 是 
“我 为 这 篇 文章 的 长 度 而 抱歉 ， 如 果 我 有 足够 多 的 时 间 ， 一 定 会 把 它 写 
得 短 一 点 。” 再 次 被 作者 逗乐 了 ， 浏 览 了 一 下 发 现 篇 幅 果 然 很 长 。 还 是 
等 QUIC 哪 天 真正 流行 了 ， 再 单独 为 它 写 一 篇 吧 。 


假装 产品 经 理 


由 于 我 最 近 经 常 评论 手机 App 的 设计 细 和 ， 所 以 被 一 位 靳 认识 的 网 
友 问 ,“ 你 是 产品 经 理 吧 ? 连 这 个 都 知道 。” 

被 误 认 为 产品 经 理 可 不 算 好 事 ， 因 为 很 多 “程序 猿 * 眼 中 的 “产品 狗 ” 
就 是 技术 浴 漆 《虽然 我 不 是 这 样 认 为 的 ， 各 有 所 长 嘛 ) 。 不 过 这 一 问 
倒是 提醒 了 我 ， 互 联网 行业 的 产品 经 理 们 也 可 以 学 学 Wireshark 的 。 如 
果 需 要 人 研究 对 手 的 产品 ， 用 不 着 派 间谍 去 偷 文档 ， 抓 个 包 仔 细 分 析 整 
能 得 到 不 少 信息 ，《 和 寻找 HttpDNS》 中 提 到 的 IP 绥 存 便 是 极 好 的 例子 。 
如 果 只 是 想 改 进 自己 的 产品 ， 抓 个 包 看 看 可 能 也 有 意外 收获 。 就 像 
Windows 上 目 市 的 FTP 客 户 端 有 个 存在 多 年 的 bug， 测 试 时 很 难 发 现 ， 


但 用 Wireshark 一 打开 束 一 目 了 然 ， 详 情 可 见 我 上 一 本 书 中 的 《一 个 古 
老 的 协议 一 一 FTP》 

今天 我 束 假 状 一 下 产品 经 理 ， 用 Wireshark 分 析 一 下 微 博 APP 是 起 
样 上 传 和 下 载 图 片 的 ， 这 对 一 个 社交 App 来 说 至 关 重 要 。 实 验 过 程 很 简 
单 ， 启 动 抓 包 后 执行 以 下 步骤 。 

1. 新 建 微 博 并 选择 一 张 3.9MB 左 右 的 图 片 ， 然 后 点 “下 一 步 ”。 

2. 随便 输入 些 字符 后 点 击发 送 按钮 。 

3. 点 击 这 条 已 发 微 博 的 小 图 ， 从 而 打开 大 图 。 

4. 在 大 图 上 点 击 “ 原 图 *"， 然 后 停止 抓 包 。 

et 让 陋 标 记 ， 
一 个 恨 好 的 习惯 ， 有 助 于 分 析 过 程 中 区 分 每 一 步 。 ， 
完 用 “httpllicemp” 过 滤 一 下 抓 到 的 网 络 包 ，35 ss 都 显示 
出 来 了 。 从 图 1 可 见 ， 四 次 ping 的 标记 都 赫然 在 目 (Protocol 栏 显示 为 
ICMP) ， 因 此 很 容易 判断 哪些 包 对 应 着 哪个 步骤 。 我 把 上 传 和 下 载 图 
片 相关 的 HTTP 请 求 都 用 方 框 标 记 出 来 ， 这 样 更 加 一 目 了 然 。 


| Filter: http || icmp [= | gepression.. Clear Apply Save 

No, Source Destination Protocol Jnfo 

274 Android unistore.weibo. cn HTTP CT ET ep 
323 unistore.weibo.cn Android HTTP HTTP/1.1 200 OK (text/html) 

416 Android unistore.weibo. cn HTTP |POST /2/statuses/upload_ tilePact=send&filetoken=1882 
419 Android weibo. cn HTTP POsT /2/groupchat/query_multi?addsession=1i&uicode=10 
445 weibo.cn Android TCP [TCP Previous segment not captured] 80-~59958 [FIN, A 
465 unistore.weibo.cn Android HTTP HTTP/1.1 200 OK (text/html) 

475 Gateway Android Echo (ping) request id=0x0001, seq=434/45569, tt1=1 
476 Android Gateway ICMP) Echo (ping) reply id=0x0001,，5seq=434/45569,， tt1=6 
493 Android wbapp. mobile. sina. cn HTTP “POST /interface/f/ttt/v3/wbpullad.php?c=android&i=aa 
500 Android weibo. cn HTTP “POST /2/statuses/send?uicode=10000017&c=android&i=aa 
511 wbapp.mobile.sina. cn Android HTTP/XML HTTP/1.1 200 OK 

517 weibo. cn Android HTTP TP 1 200 OK Gappricat ion ls on 

526 Android wwl.sinaimg. cn.w.alikunlun HTTP HT 
546 wwi.sinaimg.cn.w.alikunAndroid HTTP bp 

552 Gateway Android ICMP]j Echo (ping) request fr Seq=435/45825, tt1=1 
553 Android Gateway ICMP) Echo (pin Dr ep]l 0 Ss Ee 
559 Android wwl.sinaimg.cn.w.alikunlun HTTP 

798 wwl.sinaimg.cn.w.alikun Android HTTP TCP Fast Retransm15510n] HTTP IT 200 OK JPEG JFI 
800 Gateway Android ICMP| Echo (ping) request id=0x0001, seq=436/46081, ttl1=1 
801 Android Gateway CMP} Echo g) 『 Spy 0 008, 2 
802 Android wwl.sinaimg. cn.w.alikunlun HTTP HTTP 
1244 wwl.sinaimg. cn.w.alikun Android HTTP HTTP/1.1 0 OK (JPEG JFIF Tae 

1253 Gateway Android ICMPj Echo (ping) request id=0x0001, seq=437/46337, ttl1=1 
1254 Android Gateway ICMP) Echo (ping) reply id=0x0001，seq=437/46337,， tt1=6 


接 下 来 再 看 看 每 一 步 都 发 生 了 什么 。 在 第 一 次 ping 之 前 ， 我 的 操作 
是 在 微 博 上 选择 手机 里 一 张 3.9MB 的 图 片 ， 然 后 点 击 “ 下 一 步 *»。 本 以 为 
这 个 操作 只 发 生 在 手机 本 映 ， 所 以 不 会 有 网 络 流量 产生 。 没 想到 微 博 
App 在 这 一 步 就 已 经 上 传 图 片 了 ， 从 图 1 可 见 它 用 了 两 个 POST 来 上 传 

(274 和 416 两 个 包 ) 。 如 果 点 开 网 络 包 的 话 ， 还 可 以 从 详情 中 看 到 总 

共 传 输 了 320KB。 这 一 步 至 少 透 露出 微 博 的 产品 经 理 作 了 如 下 考量 。 

:图 请 补 选 定 之 后 束 开 始 上 传 ， 而 不 是 等 到 用 户 点 击发 送 按钮 之 
后 。 这 样 可 以 让 用 户 感觉 更 流畅 ， 好 像 点 一 下 按钮 就 瞬间 传 完了 。 当 
然 提前 上 传 也 有 人 负面 作用 : 假如 用 户 选 定 了 多 张 图 乒 并 点 击 “* 下 一 
步 *， 但 是 在 发 送 前 又 改变 主意 了 ， 于 是 点 了 “取消 ”， 这 样 用 户 以 为 自 
己 没有 发 过 任何 图 片 ， 但 其 实 多 张 图 片 的 流量 都 浪费 了 。 

:3.9MB 的 图 片 只 用 了 320KB 的 流量 ， 说 明 微 博 APP 在 上 传 图片 之 前 
会 完 大 幅度 压缩 ， 这 就 是 为 什么 美女 们 好 不 容易 PS 完 照片 发 出 去 ， 看 
到 的 效果 却 很 糟 焙 。 用 网 页 版 上 传 就 不 会 压缩 得 这 么 严重 ， 这 也 许 是 
因为 产品 经 理 考虑 到 手机 用 户 是 按 流量 计 费 的 ， 而 网 页 版 用 户 一 般 都 
用 包月 宽 市 。 

接着 往 下 看 。 在 第 二 次 ping 之 前 ， 我 的 操作 是 点 击发 送 按钮 ， 所 以 
看 到 两 个 POST 〈 包 号 493 和 500) 是 情理 之 中 的 。 只 有 526 号 包 
“GET/webp360/70398db5 jwlepzpi0g292j20xc18 gdo8.jpg” 比 较 令 人 疑 
惑 ， 为 什么 点 发 送 的 时 候 还 会 有 GET 图 片 的 操作 ? 其 实 这 时 已 经 发 送 
完毕 ， 开 始 下 载 小 图 并 显示 出 来 了 。 如 有 果 你 观察 足够 仔细 ， 会 发 现 图 
片 被 上 传 到 了 unistore.weibo.cn 〈 见 274、416 等 包 ) ， 而 下 载 时 却 是 走 
alikunlun ( 见 526 等 包 ) 。 放 Google 一 搜 ， 原 来 阿里 昆仑 是 阿里 云 CDN 
的 内 部 名 字 。 好 吧 ， 本 来 只 是 想 分析 一 下 产品 设计 ， 没 想到 连 商业 上 
的 信息 也 不 小 心 看 到 了 ， 新 浪 一 定 是 把 微 博 的 CDN 委 托 给 阿里 云 了 。 

插播 一 个 读者 疑问 ， 为 什么 在 这 本 书 的 截图 中 ，Wireshark 会 把 IP 
地 址 显示 成 域名 呢 ? 其 实 只 要 义 上 View 一 Name Resolution ~ Enable for 


Network Layer 束 行 了 ， 步 又 如 岁 2 所 示 。 
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图 2 
接 下 来 再 看 看 第 三 次 ping 之 前 的 那个 操作 ， 即 点 开 微 博 大 图 时 的 
。 如 图 3 所 示 ， 窜 户 端 通 过 GET 下 载 了 一 张 图 片 , “Content-Length: 
0 不 小 ， 只 和 镜 下 156KB 左 右 了 ， 
又 压缩 掉 一 半 。 这 APP 真 会 给 用 户 省 流量 。 


Filter: | http || icmp [>| Expression.. Clear Apply Save 

No. Time Source Destination Protocol Info 

559 20.044203000 Android wwl.sinaimg. cn. HTTP GET /woriginal/70398db5jwlepzpi0g292j20xcl8gdo8. jpg 
798 20.670907000 wwl.sinaimg.cn.Android HTTP HTTP/1.1 200 OK (JPEG JFIF image) 

800 23.288365000 Gateway Android ICMP Echo (ping) request id=0x0001, seq=436/46081, tt1=] 
801 23.370392000 Android Gateway ICMP Echo (ping) reply id=0x0001, seq=436/46081,， tt1=( 


*| Wh 


=- Hypertext Transfer Protocol 

+ HTTP/1.1 200 OKNrNn 
Server: Tengine\r\n 
Content-Type: image/ijpeg\r\n 


Content— -Length: 155971 hr\n 


出 


图 3 

微 博 大 图 上 还 有 个 “ 原 图 ”按钮 ， 我 一 点 击 又 产生 了 图 4 的 流量 ， 这 
次 下 载 的 图 是 320KB 左 右 。 可 见 微 博 认为 的 原 图 是 APP 上 传 前 压缩 过 的 
那个 ， 比 起 真正 的 原 图 (3.9MB) 还 是 小 很 多 。 


Filter | http || icmp [= | Expression.. Clear Apply Save 


Source Destination Protocol Info 
802 24.994920000 Android wwl.sinaimg.cn.HTTP GET /]arge/70398db5jwlepzpi09g292j20xc18gdo8. jp9g 


1244 26.240821000 wwl.sinaimg.cn. Android HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
< UL 


EE Hypertext Transfer Protoco 
+ HTTP/1.1 200 oOoK\r\n 


。 r 
server : Tengine\r\n 


Content-Type: image/ijipeg\r\n 
9 Content-Length: En 


图 4 
在 图 片 处 理 这 一 点 上 ， 本 山寨 产品 狗 只 能 看 出 这 么 多 了 。 正 有 牌 的 
品 经 理 如 果 有 心 去 钉 研 ， 相 信 还 能 找 出 更 多 来 。 要 是 想 知 道 微 博 的 
其 他 的 层 细 方 ， 比 如 负载 均衡 或 者 文本 加 密 等 ， 也 完全 可 以 设计 一 些 
实验 ， 然 后 抓 包 来 研究 。 我 个 人 的 下 一 个 研究 对 象 则 是 某 款 流行 的 手 
机 游戏 ， 相 信和 社交 应 用 会 大 有 不 同 。 


有 家 公司 找 我 分 析 了 几 个 网 络 包 ， 事 后 很 感激 地 说 ,“ 林 工 在 网 络 
行业 做 了 很 多 年 吧 ? ”我 只 好 如 实 相 告 , “其实 我 是 存储 行业 的 ， 看 包 
只 是 业余 爱好 。” 这 回答 听 上 去 像 是 老林 爱 吹 牛 的 毛病 又 犯 了 ， 但 的 确 
是 实话 。 我 身边 还 有 很 多 “不 务 正业 ”的 朋友 ， 比 如 读 化 学 出 身 的 冬瓜 
头 ， 年 纪 轻 轻便 写 了 本 书 叫 《大 话 存储 》， 把 存储 技术 的 方方面面 都 
复 兰 到 位 了 ， 而 我 这 个 在 存储 行业 措 爬 滚 打 了 十 来 年 的 老人 却 只 慌 文 
件 系统 和 卷 这 两 层 。 男 一 位 朋友 @ 蚀 尖 家 的 花卷 也 是 如 此 ， 这 几 年 翻 
译 了 好 多 本 IT 方面 的 书 ， 从 操作 系统 到 密码 学 都 有 涉及 ， 更 神奇 的 是 
他 还 是 果 壳 科普 达 人 ， 还 有 个 三 产 是 做 音 啊 服 务 的 。 可 见 在 这 个 信息 
爆炸 的 时 代 ， 很 多 行业 的 门板 已 经 被 网 络 填 平 了 ， 有 志 者 皆 可 跨 界 入 
门 ， 经 过 努力 甚至 能 达到 专业 水 平 。 本 文 要 分 享 的 ， 束 是 我 的 一 些 自 


六 SE mA 


学 容 | ]。 


第 一 步 ， 从 浏览 权威 的 百科 网 站 开始 。 

当 我 们 下 定 决 心 学 习 某 项 技术 时 ， 到 维基 百科 阅读 相 天 词 条 是 极 
好 的 开始 。 几 乎 所 有 的 技术 都 可 以 在 上 面 找 到 ， 如 果真 的 找 不 到 ， 整 
要 考 虚 如 此 冷门 的 东西 是 否 值 得 投入 时 间 学 习 了 。 大 多 数 词 条 里 讲 到 
的 概念 都 能 链接 到 相应 的 新 词 条 ， 比 如 TCP 词 条 里 会 说 到 handshake 这 
个 概念 ， 想 多 了 解 它 就 可 以 点 进去 看 看 。 用 这 种 方式 认真 地 阅读 完 一 
个 词 条 ， 实 际 上 已 经 把 相关 的 概念 也 弄 全 了 ， 相 当 于 读 完 一 本 简略 的 
入 门 书 。 不 光 技 术 方 面 ， 历史、 政治 等 学 科 也 可 以 用 这 个 方式 来 入 
门 ， 因 为 词 条 之 间 的 关联 性 非常 有 助 于 形成 初步 的 知识 体系 ， 而 不 是 
没有 关联 的 孤立 知识 点 。 每 次 使 用 维基 百科 ， 我 都 会 不 知 不 觉 地 打开 
很 多 相关 页 面 。 比 如 本 来 只 是 想 了 解 一 下 曹操 的 生平 ， 一 不 小 心 束 把 
曹操 的 子孙 、 对 手 和 谍 臣 的 词 条 也 读 了 ， 一 下 子 觉得 人 物 天 系 清 楚 
很 多 。 

百科 网 站 那么 多 ， 我 为 什么 推荐 维基 而 不 是 其 他 ? 这 是 因为 它 比 
较 权 威 而 且 全 面 ， 引 用 和 注释 也 很 规范 。 对 一 个 初学 者 来 说 ， 信 息 的 
准确 性 是 最 重要 的 ， 否 则 误解 了 一 个 入 门 知识 点 就 可 能 毁 了 学 习 热 
情 。 维 基 百 科 唯 一 的 不 足 是 中 文 词 条 的 数量 和 质量 都 远 不 如 英文 的 ， 
不 过 也 不 用 担心 ， 都 是 很 好 懂 的 Plain English。 技 术 人 研究 到 一 定 深度 都 
是 要 读 英 文 资 料 的 ， 连 中 国学 者 写 的 顶级 论文 也 是 用 天 文 的 ， 我 们 何 
不 从 入 门 时 就 开始 适应 呢 ? 

第 二 步 ， 疼 用 搜索 引擎。 

如 果 你 求知 阁 淘 ， 一 定 不 会 满足 于 百科 网 站 ， 因 为 脑子 里 产生 的 
无 数 疑 问 会 驱使 你 四 处 寻找 管 案 。 这 时 候 身 边 有 个 大 牛 来 指点 是 最 好 
的 ， 但 是 大 牛 回 答 三 个 以 上 的 小 日 问题 束 会 失去 耐心 ， 除 非 他 一 直 在 
暗恋 你 。 怎 么 办 呢 ? 目 己 搜索 趾 。 儿 乎 所 有 技术 问题 鸭 答案 都 在 网 
上 ， 融 算 没 有 正面 答案 也 会 有 侧面 的 ， 惑 看 你 的 搜索 技能 了 。 我 个 人 
的 技巧 有 以 下 三 点 。 


.技术 方面 的 搜索 要 用 Google， 因 为 它 返回 的 头 几 条 结果 往往 就 是 
我 想 要 的 。 一 个 典型 的 例子 就 是 在 Google 和 某国 内 著名 网 站 搜 “ 三 点 透 
视 ”， 出 来 的 结果 完全 属于 两 个 不 同 的 领域 。 假 如 你 的 研究 已 经 到 了 领 
域 尖 端 ， 需 要 读 学 术 论 文 ， 那 Google 的 优势 就 更 加 明显 了 。 

-把 关键 词 翻译 成 英文 再 搜 。 世 界 上 的 技术 高 手 很 多 ， 其 中 一 些 人 
也 乐意 回答 网 友 的 提问 ， 而 这 些 回 答 大 多 是 用 英文 的 。 这 就 导致 了 英 

资料 比 其 他 语种 的 资料 丰富 得 多 ， 假 如 你 只 用 中 文 搜索 就 会 错过 这 
些 答案 了 。 不 要 怕 英 语 不 够 用 ， 开 头 也 许 是 有 点 难 ， 但 是 慢 慢 就 能 适 
应 了 。 以 我 为 例 ， 至 今 美 国 同 事 讲 的 笑话 我 还 是 完全 不 知道 笑 点 在 
哪 ， 英 文 算 很 弱 吧 ? 但 是 技术 方面 的 交流 则 毫 无 障碍 ， 因 为 英文 的 技 
术 文 档 看 得 太 多 了 。 

:不 要 忽视 图 片 搜索 的 价值 。 网 络 技术 讲解 得 好 的 文章 ， 往 往 是 有 
图 片 的 ， 而 不 是 纯 文本 。 所 以 当 网 页 搜索 得 不 到 满意 的 结果 上 时， 尝试 
图 片 搜索 ， 然 后 再 从 喜欢 的 图 片 链接 到 原 网 页 。 我 就 用 这 个 方法 找到 
过 不 少 优 秀 的 技术 博客 。 

第 三 步 ， 哺 一 本 大 部 头 。 

有 些 人 买书 很 大 方 ， 比 如 网 络 教 程 就 买 了 很 多 本 相似 的 ， 看 到 快 
递 员 打 来 的 一 大 符 书 把 自己 都 吓 到 了 ， 完 全 符合 叶 公 好 龙 的 定义 。 其 
实 没 有 必要 买 那么 多 ， 大 部 头 的 买 一 本 足 矣 ， 关 键 是 要 真 的 去 读 。 像 
我 这 种 铁 公 鸡 类 型 的 就 不 会 犯 这 种 错误 ， 买 书 的 时 候 精 挑 细 选 ， 买 来 
之 后 读 不 完 还 觉得 亏 了 。 我 现在 还 很 怀念 当年 噶 网 络 书 的 时 光 ， 每 天 
都 觉得 很 赚 。 现 在 还 有 很 多 书 是 可 以 免费 在 线 阅 读 的 ， 比 如 《The 
TCP/IP Guide》， 觉 得 对 胃口 的 话 再 点 击 Donate 按 钮 给 作者 付 点 钱 表示 
感谢 ， 我 惊奇 地 发 现 付 钱 之 后 会 读 得 更 加 认真 ， 付 得 越 多 效果 越 好 。 

第 四 步 ， 动 手 操 作 。 

“ 纸 上 得 来 终 觉 浅 ， 绝 知 此 事 要 躬 行 。” 陆 放 翁 诚 不 我 其 。 只 有 自 
己 动 手 操作 过 了 ， 才 能 理解 得 深刻 ， 甚 至 纠正 阅读 时 产生 的 误解 。 比 


如 你 可 能 已 经 把 教材 上 的 TCP 流 挖 理论 都 背 得 滚 瓜 烂熟 了 ， 但 是 遇 到 网 
络 性 能 问题 还 是 会 手足 无 措 ， 完 全 应 用 不 上 书 里 学 过 的 知识 。 这 就 需 
要 在 读书 的 同时 辅 以 动手 训练 ， 如 果 你 在 Wireshark 里 看 过 了 拥塞 重 
传 ， 看 过 了 TCP zero window， 其 至 动手 解决 了 它 ， 从 此 流 控 技术 束 会 
像 游 注 、 骑 车 一 样 成 为 你 的 日 带 属 性 ， 经 年 不 起 。 

也 许 有 人 会 问 ， 我 到 哪里 找 网 络 包 来 训练 呢 ? 其实 机 会 就 在 号 
边 ， 比 如 妹子 究 室 的 网 络 不 好 啦 ， 下 载 小 电影 变 慢 啦 ， 都 是 抓 包 分 析 
的 好 机 会 。 实 在 没有 机 会 也 可 以 目 己 创造 。 十 八 岁 以 后 学 钢 登 已 经 太 
晚 了 (因为 你 妈 已 经 打 不 过 你 ) ， 但 学 网 络 却 正 是 时 候 ， 自 己 在 家 搭 
个 网 络 实验 室 都 没 人 管 。 用 虚拟 的 网 络 设备 练习 路 由 露 命 令 ， 或 者 在 
个 人 电脑 上 搭建 Windows Domain 等 ， 都 非常 有 用 。 

能 做 好 以 上 几 点 ， 我 觉得 已 经 很 不 容易 了 ， 进 步 也 应 该 会 很 快 。 
还 有 几 点 是 我 已 经 意识 到 了 但 目 己 也 没有 做 好 的 ， 也 列 出 来 分 享 一 
Rs 

:不 要 收藏 了 文章 而 不 去 读 它 ， 那 样 是 在 浪费 时 间 。 很 多 人 看 到 技 
术 分 享 就 说 句 mark， 但 实际 上 从 来 不 会 回头 去 读 (中 枪 了 没 ? ) 。 我 
最 近 采 取 的 措施 丈 是 强迫 目 己 不 去 收藏 ， 改 成 当场 读 完 ， 能 记得 多 少 
比例 都 比 纯 收 藏 强 。 

:多 给 新 人 做 培训 。 在 准备 培训 的 过 程 中 相当 于 把 知识 点 梳理 了 一 
遍 。 为 了 确保 内 容 无 误 ， 你 可 能 还 需要 做 实验 验证 ， 这 也 是 很 好 的 练 
习 。 最 重要 的 是 ， 能 把 一 个 技术 讲 到 新 手 能 听 懂 ， 比 起 自己 慌 就 高 了 
一 层 境界 。 有 的 时 候 觉 得 和 目 己 很 全 了 ， 但 是 想 把 它 讲 出 来 或 者 写 出 来 
却 很 别扭 ， 那 就 说 明 不 是 真 的 懂 。 也 不 要 怕 分 讲 了 之 后 被 别人 抢 饭 
硫 ， 实 际 上 无 论 你 讲 得 多 精彩 ， 大 多 数 听 众 过 几 天 就 乐 了 。 

.兴趣 主导 。 很 多 领域 牛人 都 是 完全 由 兴趣 主导 的 ， 一 心 钻研 自己 
喜欢 的 技术 ， 连 领导 交代 的 工作 都 放 在 第 二 位 。 越 痢 迷 ， 越 专注 ， 水 
平 也 就 越 高 。 


-多 参加 技术 图 的 交流 。 有 些 极 客 很 宅 ， 拒 绝 任 何 社 区 ， 并 以 此 为 
采 。 我 觉得 这 是 把 缺点 当 作 优 点 了 ， 其 实 技 术 交 流 是 非常 有 利于 进步 
的 ， 很 多 同行 也 是 相当 有 趣 的 人 。 比 如 我 曾经 被 一 个 难题 困 住 了 好 
久 ， 没 想到 跟 淘宝 技术 保障 的 朋友 一 聊 ， 他 立即 就 指 了 一 条 明 路 。 虽 
然 他 也 不 是 业内 的 大 人 物 ， 但 是 技术 背景 互补 ， 合 作 起 来 相当 高 效 。 
当然 了 ， 交 友 从 来 部 不 只 是 为 了 互助 ， 聊 得 投机 才 是 最 重要 的 。 

以 上 都 是 我 的 个 人 经 验 ， 不 一 定 会 适合 你 ， 但 布 望 有 些 参考 价 


言 恩 源 是 wwwipip.net 。 
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两 个 项 目 


这 一 部 分 只 有 两 篇 文章 ， 但 是 篇 幅 都 比较 长 。 第 一 篇 介绍 了 我 主 
导 开 发 的 一 个 网 络 性 能 分 析 网 站 ， 也 许 它 的 功能 不 是 你 需要 的 ， 但 是 
开发 过 程 可 以 参考 。 比 如 说 ， 你 也 可 以 利用 tshark 命 令 开发 一 个 监控 上 
网 记录 的 工具 ， 用 “tshark-r(file_name)-Y“http.request.full_uri”-T fields-e 
http.request.full_uri” 一 句 命 令 就 可 以 生成 原始 数据 ， 然 后 再 编程 做 二 次 
分 析 。 第 二 篇 介绍 了 网 络 加 速 器 ， 现 在 才 创 业 做 这 个 显然 太 晚 了 ， 不 
过 Wireshark 很 适合 用 来 分 析 加 速 右 的 很 多 知识 点 ， 在 实际 中 也 大 有 用 
武之 地 。 


打造 目 己 的 分 析 工 具 


Wireshark 好 不 好 ? 当然 好 ， 几 乎 称 得 上 业界 最 好 ， 否 则 我 也 不 会 
为 它 写 了 两 本 书 。 不 过 话说 回来 ， 再 好 的 工具 也 有 改进 的 空间 ， 比 如 
我 能 看 到 的 不 足 之 处 束 有 两 点 。 

:对 于 特定 职业 的 人 群 来 说 ，Wireshark 的 很 多 功能 是 完全 用 不 到 
的 。 比 如 同一 个 公司 的 开发 团队 和 运 维 团队 ， 说 起 来 都 在 用 
Wireshark， 但 实际 上 使 用 的 是 完全 不 同 的 功能 。 初 学 者 上 手 时 根本 不 
知道 哪些 功能 适合 自己 的 工作 ， 不 得 不 在 探索 上 浪费 很 多 时 间 。 

每 个 人 常用 的 功能 就 那么 儿 个 ， 却 分 布 在 不 同 的 菜单 里 ， 有 些 还 
汤 得 很 深 。 比 如 要 查看 NFS 的 读 写 啊 应 时 间 ， 需 要 点 五 次 姐 标 才能 找 


到 ， 初 学 者 根本 记 不 住 。 

有 没有 办 法 “定制 ”一 个 分 析 工 具 ， 只 提供 我 感 兴趣 的 功能 ， 而 且 
简单 到 一 键 就 能 完成 分 析 呢 ? 也 许 在 工业 4.0 时 代 会 有 这 个 服务 ， 不 过 
在 此 之 前 ， 我 们 只 能 自己 开发 了 。 今 年 我 就 和 同事 做 了 一 个 ， 本 文 会 
详细 地 加 以 介绍 ， 和 希望 对 你 有 些 参考 价值 。 

我 们 的 项 目 需求 是 这 样 的 。 

.我 司 有 很 多 团队 需要 和 网 络 打交道 ， 比 如 虚拟 化 、 云 计算 、 网 络 
存储 、 镜 像 和 备份 等 。 大 多 数 网 络 问题 都 很 好 解决 ， 但 性 能 问题 却 是 
公认 的 难点 。 

:我 司 的 这 些 团队 成 员 都 具备 网 络 基础 知识 ， 比 如 熟 恋 《TCP/IP 详 
解 卷 1: 协议 》， 但 是 缺乏 网 络 包 分 析 技 能 ， 也 没有 时 间 学 习 
Wireshark ° 

假如 有 一 个 专门 的 工具 来 分 析 网 络 性 能 ， 生 成 的 分 析 报 告 也 简单 
易 懂 ， 肯 定 会 大 受 欢迎 的 。 我 期 望 这 个 工具 能 好 用 到 什么 程度 ? 无 需 
任何 培训 ， 只 要 丢 个 网 络 包 进去 ,一 份 人 人 可 以 读 懂 的 分 析 报 告 就 出 
来 了 。 考 虑 到 这 些 团 队 在 地 理 上 非常 分 散 ( 住 在 不 同 国家 ) ， 行 政 上 
也 属于 不 同 部 门 ， 我 决定 把 这 个 工具 做 成 Web 的 形式 ， 以 便 推广 和 维 
护 。 接 下 来 就 通过 一 个 真实 的 案例 ， 演 示 一 下 它 究 况 有 多 好 用 。 

案例 症状 

用 户 抱 人 怨 某 系统 运行 起 来 非常 慢 ， 这 个 系统 的 功能 是 处 理 一 些 网 
络 存储 上 的 数据 。 

排查 过 程 

1. 把 一 些 要 处 理 的 数据 复制 到 该 系统 所 在 的 本 地 硬盘 ， 运 行 速度 
束 上 去 了 ， 说 明 该 系统 本 身 没有 问题 。 

2， 网 络 工 程 师 经 过 一 系列 检查 ， 在 网 络 上 没有 发 现任 何 问 题 。 

3. 存储 工程 师 看 到 存储 的 响应 非常 快 ， 所 以 也 没有 发 现 问 题 。 


每 一 方 都 号 称 自己 没有 问题 ， 那 用 户 该 怎么 办 ? 最 后 只 好 抓 了 个 
包 ， 上 传 到 我 们 的 工具 上 分 析 。 图 1 就 是 该 工具 的 首页 ， 它 的 全 称 为 
Network Performance Analyzer， 人 简称 NPA。 用 户 唯 一 需要 做 的 就 是 把 网 
络 包 拖 进 方 杠 ， 然 后 点 一 下 Upload 按 钮 。 
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Drag Network Trace file into the box below and click Upload! 


图 1 
几 秒 钟 后 ， 分 析 报 告 就 出 来 了 。 从 上 往 下 分 别 是 “概况 分 析 *”、“ 应 
用 层 分 析 ”、“ 传 输 层 分 析 ” 等 ， 下 面 我 会 逐 项 介绍 。 


图 2 显示 的 是 “概况 分 析 *， 目 的 是 给 用 户 呈 现 一 个 直观 的 性 能 状 
况 。 比 如 “Data bytes rate: 22 kBps” 和 和 “Capture duration: 900 seconds”， 
表明 在 抓 包 的 900 秒 里 ， 平 均 性 能 才 22KB/s， 实 在 是 很 差 。 流 量 图 的 柱 
体高 度 起 伏 不 大 ， 说 明 这 段 时 间 内 传输 均匀 ， 没 有 爆发 性 的 流量 或 者 
暂停 。 
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Summary 


Number of packets 
Average packet Size: 346.54 bytes 
Connection 


Flow Analysis 


Flow Analysis 


接 下 来 是 “应 用 层 分 析 ”， 有 具体 可 见 图 3。 该 工具 自动 判断 出 这 个 包 
的 应 用 层 协 议 是 NFSv3， 因 此 把 NFS 啊 应 时 间 (Service Response 
Time，SRT) 和 IO Size 统 计 了 出 来 。 从 图 中 的 第 一 个 方 框 可 见 READ 的 
平均 响应 时 间 是 0.226 毫 秒 ， 算 非常 好 了 “。 可 是 从 第 二 个 方 框 却 看 到 每 
次 读 的 数据 量 只 有 975 字 节 ， 还 不 到 1KB， 实 在 是 太 小 了 。 这 束 像 用 货 
车 从 北京 往 上 海运 1000 个 包 右 ， 假 如 每 次 能 运 100 个 ， 那 10 个 来 回 时 间 
就 搞定 了 。 而 假如 每 次 只 能 运 1 个 ， 玖 得 跑 1000 个 来 回 ， 那 浪费 在 路 上 
的 时 间 就 非常 可 观 了 。 因 此 ， 这 个 案例 的 解决 方式 就 是 调整 软件 的 IO 
Size， 增 大 到 每 次 读 64K 字 节 ， 人 性 能 立即 得 到 大 幅度 提升 。 你 可 能 会 好 
奇 ， 为 什么 同样 的 IO Size， 处 理 本 地 硬盘 上 的 数据 束 没 有 性 能 问题 
呢 ? 这 就 是 网 络 的 弱点 了 ，TCP/IP 儿 层 处 理 下 来 ， 总 会 增加 一 些 延迟 
的 。 当 来 回 次 数 特别 多 的 时 候 ， 延 运 的 效应 束 税 放大 了 。 
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NFSv3 SRT 


Procedure Min SRT (s) Max SRT (s) Avg SRT (s) Total (s) 
GETATTR 0.000000 0.003907 0.000012 0.042969 
LOOKUP 549 0.000000 0.003907 0.000019 0.121093 
ACCESS 0.000000 0.023437 0.000013 0.109372 

0.000000 0.019531 0.000226 1.941406 
WRITE 0.000000 0.000000 0.000000 0.000000 
CREATE 5 0.000000 0.003906 0.000781 0.011718 
REMOVE 0.000000 0.003906 0.000434 0.003906 
RENAME 0.000000 0.003906 0.000617 0.011718 
READDIR 0.000000 0.000000 0.000000 0.000000 
READDIRPLUS 6 0.000000 0.000000 0.000000 0.000000 
FSSTAT 0.000000 0.000000 0.000000 0.000000 


COMMIT 5 0.000000 0.003906 0.000260 0.003906 


NFSVv3 IO Size 


There were 8584 read operations with average size 975 bytesland 15 write operations With average size 
3865 bytes 


图 3 
既然 在 应 用 层 就 已 经 找到 症结 ， 我 们 也 没 必要 再 去 看 传输 层 了。 
不 过 传输 层 可 是 性 能 问题 的 高 发 区 ， 也 是 这 个 工具 的 特长 之 处 ， 所 以 
我 忍 不 住 再 给 大 家 看 两 个 案例 。 
图 4 是 VMware 性 能 差 的 案例 。 抓 包 分 析 后 ， 发 现 总 共 250 秒 的 抓 包 
时 间 里 ， 有 190.8 秒 被 浪费 在 延迟 确认 上 了 ， 用 上 这 文 工 具 之 后 简直 就 是 


秒杀 。 由 于 本 书 是 畸 日 印刷 的 ， 所 以 看 不 出 该 工具 已 经 把 出 问题 的 所 
示 文 本 设置 成 红色 背景 ， 实 际 上 有 是 非常 醒目 的 。 
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Delayed ACK 


Among the 2057 pure ACKSs, WaSRL 192.168.100.243 and 954 ACKSs from 192.168.100.220 mighi 


be Delayed ACKSs 


Each Delayed ACK takes about 0.2 second, which means 190.8 seconds have been wasted in this 
connection. You may disable Delayed ACK ifthe impact is high 


图 4 
图 5 则 是 我 上 一 本 书 的 《 深 藏 功 与 名 》 文 章 中 提 到 过 的 某 银 行 
例 ， 根 本 原因 是 网 络 拥塞 导致 的 丢 包 ， 而 且 SACK 也 没有 启用 ， 两 个 根 
源 都 被 这 工具 分 析出 来 了 。 当 时 要 是 用 上 这 工具 ， 也 是 很 快 就 能 解决 
的 。 


| 


圈 EMc Network Performanc x WO 
€ SC (npacom/connection/5d1153ea-c558-4f27-b459-9a7c83af8609/0 


TCP Retrans 
Among the 91379 packets, WBA a LA 901 of them were 


retransmitted from 10.70.16.10 to 10.72.15.10 , and 0 of them were retransmitted from 10.72.15.10 to 
10.70.16.10 . 


The Retransmission rate over 0.1% indicates a network congestion, and 0.01% ~ 0.1% is questionable. If 
this retransmission rate is considered as high for your product, please work with network team to figure 
out the cause. Limiting the TCP window or extending the bandwidth could reduce retransmission. 


TCP SACK 


SACK was not enabled in this TCP session, please check both sides to enable SACK. Enabling SACK 
could reduce the impact of retransmission 


我 手头 的 案例 还 有 很 多 很 多 ， 篇 幅 所 限 殉 不 一 一 列举 了 “。 可 以 
说 ， 我 司 的 大 多 数 网 络 性 能 问题 都 可 以 用 这 个 工具 找到 症结 。 有 很 多 
团队 已 经 从 中 受益 ， 因 为 他 们 不 用 再 请 林 沛 满 吃饭 看 包 了 ， 目 助 就 能 
完成 。 我 当然 也 很 高 兴 ， 因 为 得 以 摆脱 耗 时 的 重复 性 劳动 ， 有 了 更 多 
的 时 间 可 以 带 娃 。 看 到 这 里 ， 不 知道 你 是 否 也 想 打 造 一 个 适合 目 己 职 
业 的 分 机 工具 呢 ? 有 兴趣 的 话 可 以 参考 我 的 开发 过 程 ， 大 致 可 以 分 为 
三 

第 一 步 : 收集 旧 问 题 。 

我 们 不 可 能 开发 一 套 具有 人 工 智能 的 程序 来 分 析 网 络 包 。 换 句 话 
说 ， 自 己 打 造 的 工具 本 质 上 不 会 比 Wireshark 更 聪明 。 不 过 我 们 可 以 把 
和 目 己 的 工作 经 验 * 传 授 ” 给 这 个 程序 ， 使 它 看 上 去 比 Wireshark 智 能 很 
多 。 要 如 何 做 到 呢 ? 世界 上 绝 大 多 数 故 障 都 不 是 第 一 次 发 生 的 ， 有 经 
验 的 工程 师 可 以 把 处 理 过 的 旧 问 题 收集 起 来 ， 归 纳 出 每 个 问题 在 网 络 
包 中 各 有 什么 特征 。 以 后 抓 到 新 的 包 ， 束 可 以 用 这 些 已 知 特征 逐个 去 
僚 ， 一 旦 发 现 匹 配 得 上 的 束 提 示 用 户 。 比 如 我 已 知 有 20 个 原因 会 影 啊 
网 络 性 能 ， 每 个 原因 在 网 络 包 中 都 会 有 一 些 特征 ， 就 可 以 在 新 抓 的 网 
络 包 里 用 这 20 个 特征 去 逐个 匹配 。 一 旦 发 现 有 符合 的 就 提醒 用 户 ， 就 
像 图 4 和 图 5 那样 。 

Wireshark 需 要 用 户 点 击 多 个 按钮 才 会 去 分 析 ， 但 我 们 的 工具 会 主 
动 分 析 并 生成 报告 ， 这 对 用 户 来 说 就 是 和 关 能 化 的 体验 。 不 只 是 网 络 性 
能 问题 ， 任 何 网 络 相 天 的 技术 领域 都 可 以 采用 这 个 方法 ， 比 如 从 事 
Windows Domain 相 天 工作 的 拉 术 人 员 ， 可 能 保存 着 上 百 个 常用 的 微软 
KB ， 其 中 包括 DNS 解析 出 销 、Authenticator 过 大 、UDP 包 被 切 分 丢 
径 ， 等 等 。 这 些 问 题 都 可 以 在 网 络 包 中 以 时 个 特征 体现 出 来 ， 因 此 也 
可 以 写成 程序 去 匹配 。 网 管 员 做 监控 也 是 如 此 ， 很 多 场景 都 是 固定 
的 。 


把 这 些 旧 问题 收集 好 了 ， 束 已 经 同 成 功 迈 出 一 大 步 。 不 过 实际 做 
起 来 可 没 那 么 轻松 ， 你 也 许 需 要 召集 团队 中 最 有 经 验 的 工程 师 ， 收 集 
他 们 的 需求 和 抓 过 的 网 络 包 ， 然 后 再 筛选 和 测试 。 在 这 一 步 收集 到 的 
旧 问 题 有 多 全 面 ， 束 决定 了 你 做 出 来 的 工具 有 多 强大 。 

第 二 步 : 用 tshark 来 做 匹配 。 

tshark 是 Wireshark 的 命令 行 形式 ， 适 合 被 其 它 程序 调用 来 分 析 网 络 
包 ; 再 加 上 其 分 析 结 果 是 文本 输出 的 ， 所 以 作 二 次 加 工 也 很 方便 。 基 
于 这 两 点 ， 选 用 tshark 来 匹配 已 知 的 特征 是 最 合适 的 ， 如 采 你 已 经 在 上 
一 步 整理 出 了 20 个 特征 ， 那 么 再 编辑 20 条 tshark 命 令 束 基本 可 以 搞定 
7 。 tshark 命 令 的 使 用 方法 在 上 一 本 书 中 已 经 介绍 过 ， 这 里 吏 不 重复 

。 简单 举 个 的 例子 ， 已 知性 能 问题 的 特征 之 一 是 TCP 重 传 ， 那 执行 下 
Ss 命令 瓯 可 以 匹配 了 : 


tshark-n-q-r<file_ name>-z io, stat, 0, tcp.analysis.retransmission, 


“tcp.analysis.retransmission and ip.src==<IP_A>” ， 
“tcp.analysis.retransmission and ip.src==<IP_B>” 
输出 示例 如 下 : 


吗 Command Prompt 


i 


C: \Users\linpi\Desktop\StarIlI\Samples>tshark -n -gq -r sample_filter.cap 
tcp.analysis.retransmission and ip.src== i100.72. 1 i109" 


IO Statistics 


上 Duration: 56.5 secs ! 
Interval: 56.5 secs 


! Col 1: tcp.analysis.retransmission 
2 


| : tcp-analusis .ketkansmission and ip.src== 10.79.16.10 ! 
! 3: tcp-.analysis.retransmission and ip.src== 108.72.15.10 ! 
! 11 12 13 | 
! Interval ! Frames ! Bytes ! Frames ! Bytes ! Frames 上 Bytes ! 
@.0 <> 56.5 981 1364114 981 1364114 @ @ 


C:\Users\linpli\Desktop\StarlI\Samples >», 


4 | Mm 


图 6 

在 图 6 的 输出 中 ， 列 1 的 Frames 表 示 所 有 重 传 包 数 ， 列 2 表示 从 IP_A 
到 IP_B 的 重 传 包 数 ， 列 3 表示 从 IP_B 到 IP_A 的 重 传 包 数 。 有 了 这 些 值 就 
很 容易 统计 重 传 率 和 重 传 方向 。 

当 你 不 知道 某 个 特征 所 对 应 的 tshark 命 令 是 什么 的 时 候 ， 可 以 尝试 
从 Wireshark 中 把 它 找 出 来 ， 然 后 右键 点 击 该 特征 ， 选 择 “Prepare a 
ee 就 可 以 在 过 滤 栏 生成 表达 式 了 ， 如 图 7 所 示 。 有 了 

文 个 表达 式 就 很 容易 应 用 到 tshark 命 令 中 。 


Filter | tcp,analysis,fast_retransmission 四 Expression... Clear Apply Save 

No. Time Source Destination Protocol Info 

166 0.102757000 Client Sserver TCP [TCP Fast Retransmission] [TCP segment of a rei 
167 0.102771000 server Client TCP 3260-61965 [ACK] Seq=145 Ack=58401 Win=1024 Lel 
168 0.102778000 Client server TCP [TCP seqment of a reassembled PDU] 

* 


WH 


习 3 [Expert Info (Note/sequence) : This frame is a (suspected) fast retransmission] 
his 


[severity level: Note] Expand Subtrees 


[Group: Sequence] Collapse Subtrees 
[Expert Info (Note/sequence): This fram Expand All 
TCP segment data (1460 bytes) Collapse All 
0000 00 60 16 36 10 44 00 2a 6a b9 b0 41 08 ol 


0010 05 dc a8 51 40 00 7e 06 1b 29 0a 46 10 0! Appysscoumn 
0020 of 0a f2 0d Oc bc 78 d9 55 bd f8 45 45 2] 
0030 80 00 02 b3 00 00 43 6f 6d 62 69 6e 65 6| 
0040 72 6f 64 75 63 74 20 61 6e 64 20 43 6f 6| 
NNSN fF1 63 74 2n0 S23 7S FRI SA Ff 74 F1 fr 77 7 


图 7 

还 有 些 命令 是 不 能 用 这 个 方法 找到 的 ， 只 能 自己 查 tshark 的 官方 广 
档 了 ， 和 链接 为 http://www.wireshark.org/docs/man-pages/tshark.html 。 
tshark 命 令 真 的 非 第 强大 ， 如 采用 得 好 ， 可 以 实现 很 多 专业 软件 特有 的 
功能 

这 一 步 的 tshark 命 令 写 得 有 多 精确 ， 束 决定 了 你 开发 出 来 的 工具 有 
多 可 靠 。 

第 三 步 : 程序 化 。 

0 你 已 经 整理 了 很 多 第 见 的 问题 ， 并 知道 如 何 用 tshark 命 
令 来 匹配 它们 ， 是 时 候 写 个 程序 来 完成 整 项 工作 了 。 比 如 说 ， 上 一 步 
从 tshark 输 出 中 得 到 了 重 传 的 包 数 ， 那 就 可 以 用 程序 来 计算 重 传 率 ， 并 


Apply as Filter 上 


Prepare a Filter 上 Selected 


决定 是 否 应 该 通知 用 户 。 这 个 程序 可 得 好 好 设计 ， 因 为 它 关 系 到 运行 
效率 〈《 当 你 抓 到 的 网 络 包 非常 大 时 ， 就 会 发 现 运行 效率 是 极其 重要 
的 ， 否 则 等 半 个 小 时 都 没有 结果 ) 。 举 个 例子 ， 应 用 层 上 有 HTTP、 
FTP、iSCSI、NFS、CIFS 等 协议 ， 每 一 个 协议 都 有 不 同 的 问题 ， 每 个 
问题 又 对 应 着 不 同 的 tshark 命 令 。 我 们 总 不 能 拿 到 一 个 网 络 包 ， 就 把 所 
有 tshark 命 令 都 运行 一 次 吧 ? 那样 效率 太 低 了 。 正 确 的 方法 是 让 程序 先 
判断 包 里 的 应 用 层 协 议 是 什么 ， 然 后 再 调用 其 相关 的 命令 。 那 怎样 知 
道 抓 到 的 包 是 什么 协议 的 呢 ? 我 们 可 以 根据 端口 号 来 判断 ， 比 如 端口 
号 为 80 时 ， 束 调用 HITTP 相 天 的 命令 ， 端 口号 为 445 时 ， 残 调用 CIFS 相 
天 命令 ...... 还 有 些 实在 无 法 用 程序 自动 判断 的 ， 可 以 由 用 户 来 辅助 完 
成 。 比 如 在 页 面 上 提供 多 个 按钮 ， 对 应 着 不 同 的 协议 ， 让 用 户 自己 选 
择 。 总 而 言 之 ， 产 品 经 理 必须 非常 熟悉 业务 流程 ， 才 能 把 这 个 程序 写 
得 高 效 、 科 学 、 友 好 。 

那 用 什么 语言 来 写 这 个 程序 最 好 ? 这 个 没有 定 法 。 我 们 早期 是 用 
Penl 写 的 命令 行 脚 本 ， 开 发 简单 ， 运 行 速度 也 快 。 但 它 也 有 致命 的 缺 
点 ， 就 是 界面 不 美观 ， 推广 和 升级 也 很 麻烦 。 后 来 我 们 改 用 
Python+Flask 做 成 了 Web 的 形式 ， 还 请 专业 美工 人 士 设 计 了 界面 ， 效 果 
束 好 多 了 “。 作 为 一 个 有 强迫 症 的 伪 产 品 经 理 ， 我 还 想 强调 细节 的 重要 
性 ， 比 如 了 网络 包 分 析 过 程 中 ， 一 定 要 在 页 面 上 显示 一 个 转动 的 移 人 花 来 
延长 用 户 的 耐心 ， 见 图 8 。 不 要 小 看 这 种 小 细节 ， 如 果 分 析 时 间 超 过 三 
分 钟 ， 又 没有 菊花 在 转动 ， 用 户 很 可 能 以 为 程序 已 经 死 了 ， 然 后 就 点 
刷新 ， 又 得 从 头 再 来 一 次 。 对 细节 的 重视 程度 ， 很 大 程度 上 决定 了 这 
个 工具 的 用 户 体验 。 
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图 8 

这 个 工具 就 介绍 这 么 多 ， 和 硕 望 对 你 有 参考 价值 。 如 果 你 在 开发 过 
程 中 遇 到 什么 问题 ， 也 欢迎 进一步 交流 。 困 难 肯 定 会 有 的 ， 但 只 要 肯 
动手 去 做 ， 你 就 成 功 了 一 半 。 


现在 是 2015 年 初秋 ， 一 个 收获 的 季节 ， 这 本 书 也 写 到 了 尾声 。 此 
刻 我 正在 小 区 附近 的 另 啡 饮 里 ， 苦 酌 最 后 一 篇 应 该 写 些 什么 。 此 书 的 
很 多 章节 就 是 在 这 家 店 里 完成 的 ， 但 接 下 来 应 该 有 很 长 时 间 不 会 再 来 
了 ， 因 为 最 近 兴 起 的 创业 大 军 实 在 太 吵 。 领 桌 正在 激情 涪 汶 地 讨论 “ 僵 
利 模式 ”\“ 估 值 ”`\“ 收 购 ”\、“A 轮 B 轮 C 轮 ”.…… 上 周 还 听 到 一 位 从 阿里 


离职 的 工程 师 在 必 辐 同伴 出 来 一 起 开发 手机 APP， 展 望 前 景 的 语气 让 我 
想起 了 安利 的 培训 。 

其 实 我 六 七 年 前 也 产生 过 一 个 稍 纵 即 逝 的 创业 念头 。 与 现在 流行 
的 P2P、O20O 等 概念 不 同 ， 那 时 的 IT 创业 主要 集中 在 传统 的 技术 领域 ， 
比如 我 老板 做 的 数据 迁移 设备 惑 卖 了 一 个 很 好 的 价钱 。 有 趣 的 是 那 产 
品 两 年 后 就 被 淘汰 了 ， 命 运 跟 现在 的 初创 公司 很 像 。 而 我 当时 想 做 的 
是 一 个 网 络 加 速 句 ， 它 究竟 是 个 什么 东西 呢 ? 细 想 起 来 ， 它 跟 我 之 前 


讲 过 的 很 多 技术 都 有 关联 ， 不 如 最 后 一 篇 就 写 写 它 吧 ， 就 当 作 知 识 总 
结 。 

那 几 年 我 接触 了 世界 上 很 多 知名 公司 的 数据 中 心 ， 发 现 他 们 都 有 
一 样 的 痛 点 ， 即 跨 站 点 (site) 的 网 络 存在 性 能 瓶颈 。 比 如 图 1 这 样 的 
环境 中 ， 纽 约 的 用 户 访问 伦敦 的 文件 服务 器 ， 或 者 两 边 的 数据 库 做 同 
步 ， 都 会 慢 得 出 奇 。 


图 1 

这 类 问题 排查 下 去 ， 一 般 会 归根 于 带宽 不 足 ， 解 决 方式 就 是 花 钱 
购买 更 大 的 市 宽 。 然 而 很 少 人 知道 还 有 一 个 不 花 钱 的 办 法 ， 承 是 通过 
传输 层 (基本 都 是 TCP) 的 调 优 来 提高 带宽 利用 率 ， 从 而 提升 性 能 体 
验 。 那 时 候 我 已 经 学 会 了 分 析 网 络 包 ， 知 道 传统 的 TCP 协 议 栈 不 能 很 好 


地 应 对 跨 站 点 的 场景 ， 所 以 带宽 利用 率 偏 低 。 有 些 严 重 的 甚至 在 50% 以 
下 ， 因 此 存在 很 大 的 提升 空间 。 比 如 客户 从 我 司 购买 的 文件 服务 器 在 
跨 站 点 时 访问 不 快 ， 但 经 过 专业 调 优 之 后 ， 性 能 可 以 提升 两 倍 以 上 。 
这 束 是 商机 所 在 : 既然 可 以 通过 调 优 的 方式 来 达到 和 购买 带宽 一 样 的 
效果 ， 我 们 就 有 了 和 角 利 的 空间 。 接 下 来 的 问题 就 是 怎样 做 成 一 个 产品 
了 o 

人 工 调 优 能 做 到 的 事情 ， 理 论 上 程序 也 可 以 做 到 。 因 此 我 最 早 想 
做 的 产品 是 改进 型 的 TCP 协 议 栈 ， 装 在 服务 器 上 ， 使 它 在 跨 站 点 场景 中 
能 够 更 智能 地 工作 ， 达 到 人 工 调 优 后 的 效果 。 不 过 很 快 就 发 现 这 个 路 
子 走 不 通 ， 原 因 有 三 。 

.有 很 多 操作 系统 不 允许 修改 原 有 的 TCP 协 议 栈 。 比 如 我 司 的 服务 
器 就 是 完全 封 财 的 ， 第 三 方 厂商 根本 不 知道 怎么 修改 。 有 些 服务 器 虽 
然 就 是 普通 的 Linux 或 者 Windows， 技 术 上 能 够 修改 ， 但 是 厂商 声明 一 
旦 动 了 协议 栈 就 不 再 提供 技术 支持 。 

.即使 服务 器 都 用 上 了 改进 过 的 协议 栈 ， 也 会 受到 客户 端 配 置 的 约 
束 ， 难 以 充分 发 挥 。 比 如 在 客户 端 关闭 了 TCP Timestamps (RFC 
1323) ， 那 在 服务 器 上 计算 RTT (往返 时 间 ) 时 就 会 受到 影响 ， 或 者 客 
户 端 关闭 了 SACK， 那 在 服务 器 上 启用 SACK 也 没有 意义 。 

.没有 用 户 愿 意 为 了 改善 跨 数据 中 心 的 访问 ， 而 大 动 干戈 地 对 服务 
器 的 TCP 层 作出 改动 。 万 一 改动 之 后 影响 了 本 地 访问 性 能 怎么 办 ? 
注意 : 这 三 点 只 说 明 该 产品 不 适合 本 文 所 针对 的 场景 ， 而 不 是 说 它 没有 价值 。 事 实 上 它 在 
有 些 场景 下 可 以 工作 得 很 好 ， 现 在 也 已 经 有 商业 化 的 产品 了 ， 比 如 硅谷 有 家 叫 AppEx Networks 
的 公司 推出 的 单 边 加 速 器 ZetaTCP 就 不 错 。 我 后 来 才 发 现 其 CEO 是 位 华人 ， 在 北京 也 有 分 公 
司 。 市 面 上 还 有 一 些 很 滑稽 的 加 速 器 ， 比 如 通过 每 个 包 发 两 次 来 避免 丢 包 的 ， 在 我 看 来 就 是 ; 
费 流量 的 七 伤 拳 ， 不 建议 采用 。 
既然 这 个 路 子 完 全 走 不 通 ， 我 们 只 能 设计 一 个 不 同 的 产品 了 ， 它 
至 少 要 满足 以 下 需求 才 行 。 


' 它 不 需要 对 服务 器 或 客户 端的 TCP 协 议 栈 作 任何 改动 ， 所 以 实施 
的 障碍 会 小 很 多 。 

' 它 完全 独立 工作 ， 所 以 不 受 客户 端 和 服务 器 上 的 TCP 设 置 所 影 
啊 。 比 如 客户 端 上 没有 局 用 SACK 时 ， 它 也 能 处 理 好 连续 丢 包 的 问题 。 

它 只 用 于 改善 跨 数 据 中 心 的 的 网 络 性 能 ， 对 本 地 访问 毫 无 影响 。 

需求 一 旦 明确 ， 解 决 方案 便 呼 之 欲 出 了 。 如 图 2 所 示 ， 只 要 在 两 个 
站 所 的 出 口 各 目 染 设 一 台 加 速 右 ， 代 理 两 个 站 点 之 间 的 所 有 TCP 连 接 ， 
号 可 以 满足 以 上 所 有 和 需求。 由 于 每 全 加 速 器 与 同 站 点 设备 之 间 的 网 络 
状况 恨 好 ， 所 以 瓶颈 只 会 落 在 两 台 加 速 万 之 间 的 网 络 上 ， 我 们 只 需 花 
心思 提升 这 段 网 络 的 性 能 即 可 。 也 许 有 些 读者 看 到 这 里 会 觉得 好 实 ， 
现在 这 种 加 速 郁 在 国内 外 至 少 有 十 个 牌子 ， 连 开源 项 目 都 有 了 ， 你 还 
创 什么 业 啊 ? 现在 的 确 是 成 熟 的 市 场 了 ， 但 是 当年 可 完全 不 是 这 样 ， 
尤其 没有 听 说 过 国内 的 公司 。 我 也 只 是 因为 分 析 了 足够 多 的 网 络 包 ， 
便 目 然而 然 地 萌生 了 引入 加 速 詹 的 念头 。 技 术 之 外 的 话题 束 不 多 说 


纽约 


图 2 
我 们 先 来 分 析 一 下 这 段 网 络 存在 什么 问题 ， 才 能 对 症 下 药 ， 总 结 
下 来 主要 有 两 个 大 问题 。 


问题 一 : 延迟 高 。 


位 于 同一 站 点 的 两 台 设 备 之 间 往 返 时 间 一 般 也 就 儿 之 秒 ， 而 跨 城 
网 络 的 往返 时 间 可 能 达到 几 十 毫秒 ， 跨 国 网 络 甚至 可 达 上 百 毫 秒 。 高 
延迟 为 什么 会 影响 性 能 呢 ? 因为 它 会 造成 长 时 间 的 空 等 : 发 完 一 个 窗 
口 的 数据 量 后 ， 发 送 方 就 不 得 不 停 下 来 等 待 接收 方 的 确认 。 延 迟 越 
高 ， 发 送 方 需要 等 筛 的 时 间 就 越 长 。 一 图 胜 千 言 ， 图 3 演示 了 发 送 窗 口 
都 是 2 个 MSS， 延 迟 时 间 分 别 为 10 坚 秒 和 20 盈 秒 时 的 传输 过 程 ， 可 见 后 
者 效率 只 有 前 者 的 12。 这 好 比 用 同一 辆 货车 运 货 ， 从 上 海运 到 江苏 肯 
定 比 从 上 海运 到 北京 快 得 多 。 


发 送 窗口 大 小 为 2 个 MSS 发 送 窗 口 大 小 为 2 个 MSS 
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有 时 候 我 们 会 在 Wireshark 中 看 到 [TCP window Full] 的 提示 ， 就 
表明 发 送 方 进入 了 等 待 状态 。 这 种 症状 在 跨 站 点 通信 时 是 很 常见 的 ， 
具体 可 见 本 书 《Wireshark 的 提示 》 一 文中 的 图 9。 那 么 这 个 问题 要 怎么 
解决 呢 ? 在 延迟 时 间 无 法 减少 的 情况 下 ， 发 送 窗 口 越 大 ， 人 性 能 就 越 
好 ， 所 以 要 尽 可 能 增 大 窗口 。 


问题 二 : 丢 包 率 高 。 

丢 包 一 般 分 两 种 情况 : 一 种 是 网 络 质量 差 导 致 的 零星 丢 包 ; 另 一 
种 是 拥塞 导致 的 大 量 丢 包 。 跨 站 点 通信 时 这 两 种 丢 包 概率 都 会 增 大 ， 
尤其 是 后 者 。 这 是 因为 链 路 上 的 情况 比较 复 洒 ， 而 且 不 同 的 TCP 连 接 会 
“恶意 ”地 争夺 本 来 就 有 限 的 带 守 。 比 如 图 2 中 的 文件 服务 器 、 数 据 库 和 
邮件 服务 器 等 建立 的 TCP 连 接 会 各 自 为 政 ， 互 相 争 村人 带宽， 直至 发 生 丢 
包 才 停 下 来 。 这 种 情况 很 像 上 海马 路 上 的 车 辆 ， 为 了 加 速 而 变 道 的 车 
多 了 ， 就 容易 诱发 交通 事故 。 

技 包 对 性 能 的 影响 极 大 ， 可 以 说 是 网 络 传输 的 第 一 大 忌 ， 有 具体 原 
因 我 都 在 上 一 本 书 中 兰 述 了 ， 这 里 再 简单 解释 一 下 : 传统 TCP 的 访 控 机 
制 是 一 旦 丢 包 就 认为 发 生 了 拥塞 ， 所 以 发 送 方 会 急剧 地 减 小 发 送 窗 
口 ， 甚 至 进入 短暂 的 等 待 状态 ( 即 超时 重 传 ) 。1% 的 丢 包 率 不 只 是 降 
低 1% 的 性 能 ， 而 可 能 是 50% 以 上 。 这 个 问题 有 办 法 缓解 吗 ? 也 有 “。 惠 
先 可 以 尽 可 能 降低 丢 包 的 概率 ， 比 如 提前 预测 并 采取 措施 避免 拥塞 的 
发 生 ; 其 次 是 更 精细 地 处 理 丢 包 后 的 流 控 ， 避 免 过 度 限 流 。 

一 番 分 析 下 来 ， 发 现 这 两 个 问题 还 是 很 灰 手 的 ， 但 是 不 用 担心 ， 
我 们 还 手 担 王 牌 呢 一 一 在 加 速 器 上 可 以 大 做 文章 ， 大 幅度 缓解 这 两 个 
问题 所 帝 来 的 影响 。 作 为 一 个 创业 奸商 ， 其 实 我 们 应 该 希望 影响 尽 可 
能 严重 ， 带 宽 利 用 率 最 好 在 50% 以 下 。 因 为 这 意味 着 留 给 加 速 器 的 提升 
空间 就 大 了 ， 客 户 购买 之 后 能 看 到 明显 的 效果 ， 才 会 觉得 物 有 所 值 。 
接 下 来 要 介绍 的 就 是 缓解 这 两 个 问题 的 措施 ， 也 是 我 们 这 个 加 速 器 的 
技术 含量 所 在 。 

措施 1: 启用 TCP window scale 。 

这 样 可 以 使 最 大 接收 窗口 从 65，535 字 闻 ( 老 的 Windows 控 作 系 统 
甚至 只 有 17520 字 节 ) 增加 到 1，073，725，440 字 节 。 发 送 窗口 是 受 接 
收 窗口 和 拥塞 窗口 共同 限制 的 ， 启 用 TCP window scale 之 后 ， 接 收 窗口 


残 几 乎 限制 不 到 了 ， 当 然 内 存 也 要 跟 得 上 才 行 。 关 于 TCP window scale 
的 更 多 信息 ， 可 参考 本 书 的 另 一 片 文章 《技术 与 工龄 》 
措施 2: 监测 延迟 来 避免 拥 蹇 。 
网 络 包 是 以 队列 的 方式 通过 网 络 设 备 的 。 当 拥塞 即将 发 生 时 ， 队 
列 变 长， 延迟 就 会 显著 提高 。 我 做 了 一 个 从 台湾 机 房 往 上 海 机 房 传 数 
据 的 实验 ， 一 般 情 况 下 的 往返 时 间 为 74 毫 秒 ( 见 图 4 方 框 中 的 RTT) ， 
而 拥塞 丢 包 发 生前 会 逐渐 增加 到 1.69 秒 以 上 。 根 据 这 一 特点 ， 我 们 可 以 
让 加 速 器 在 延迟 明显 增加 时 ， 和 上 自动 放 慢 发 送 速度 ， 从 而 避免 拥塞 的 发 
和 牛 。 
一 般 情 况 : 
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这 其 实 束 是 TCP Vegas 的 理念 。 它 用 在 服务 器 上 时 不 见得 很 好 ， 甚 
至 有 人 负 作 用 。 想 象 一 台 启 用 了 传统 TCP 协 议 栈 的 服务 器 和 一 台 启 用 了 
Vegas 的 服务 硕 抢 斋 宽 ， 当 拥塞 即将 出 现时 ， 用 Vegas 的 那 台 监 测 到 了 延 
迟 并 主动 放 慢 速 度 ， 从 而 缓解 了 拥塞 ， 但 传统 的 那 台 却 得 寸 进 尺 ， 一 
直 激 进 地 抢 带 宽 。 最 终结 果 可 能 是 传统 的 那 台 反而 赢 了 一 一 劣 币 淘 汰 
民 币 。 而 在 加 速 器 上 3 引入 Vegas 理 念 就 不 一 样 了 ， 由 于 每 个 TCP 连 接 都 
是 一 样 的 算法 ， 所 以 预测 到 拥 赛 时 大 家 可 以 集体 放 缓 ， 从 而 保证 了 公 
平 性 。 这 就 像 马 路 上 每 位 司机 都 礼貌 谦让 ， 束 不 会 发 生 事 故 ， 整 条 杞 
路 的 通行 效率 也 提高 

除了 能 预测 拥塞 ， 监 测 延 人 运 时 间 还 有 助 于 区 分 零星 丢 包 和 拥 窗 丢 
包 ， 因 为 发 生 零 星 丢 包 时 的 延迟 一 般 不 变 。 区 分 它们 有 什么 意义 呢 ? 
传统 TCP 协 议 栈 遇 到 丢 包 都 一 律 当 作 拥 塞 处 理 ， 立 即 放 慢 速度 甚至 暂 
停 。 这 样 一 刀 切 并 不 科学 ， 和 零星 丢 包 时 重 传 一 下 束 行 了 ， 没 必要 放 慢 
速度 。 

措施 3: 利用 发 送 窗 口 实现 优先 级 。 

两 个 站 点 之 间 存 在 很 多 连接 ， 且 优先 级 各 有 不 同 ， 比 如 数据 归档 
的 优先 级 就 可 能 低 于 其 它 应 用 ， 可 以 传 慢 一 点 。 我 们 的 加 速 器 代理 了 
两 个 站 点 之 间 的 所 有 连接 ， 因 此 很 容易 通过 调和 各 个 连接 的 发 送 窗 口 
来 实现 优先 级 控制 。 优 先 级 低 的 连接 变 慢 了 ， 就 可 以 把 带宽 让 给 优先 
级 高 的 连接 ， 用 户 体验 就 会 更 好 。 

措施 4: 局 用 SACK。 

SACK 即 Selective Acknowledgment， 它 是 处 理 拥塞 丢 包 时 的 法 至 ， 
尤其 是 在 高 延迟 的 跨 站 点 环境 中 ， 详 情 可 参考 本 书 的 另 一 片 文 章 《 来 
点 有 深度 的 》。SACK 必 须 在 发 送 方 和 接收 方 都 启用 ， 这 就 是 我 们 在 两 
边 各 架设 一 台 加 速 器 的 优势 。 单 边 TCP 加 速 右 的 效果 很 可 能 因为 为 一 瘦 
没有 启用 SACK 而 大 打折 扣 。 

措施 5: 改进 慢 局 动 算 法 。 


传统 的 TCP 协 议 栈 采 用 了 非常 保守 的 慢 局 动 算法 ， 即 把 拥塞 窗口 的 
初始 值 定 义 得 非常 小 ， 不 能 大 于 4 个 MSS。 而 且 一 旦 发 生 超时 重 传 ， 又 
要 从 头 进入 慢 局 动 阶段 ， 如 图 5 所 示 。 
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图 5 

这 就 意味 着 传输 过 程 中 至 少 有 一 段 时 间 的 窗口 极 小 ， 效 率 非 常 
低 。 随 着 人 硬件 的 更 新 换代 ， 现 在 的 网 络 带宽 已 经 今 非 苷 比 了 ， 完 全 没 
必要 如 此 保守 。 作 为 一 个 专业 的 TCP 加 速 器 ， 我 们 有 必要 在 这 一 点 作出 
改进 。 比 如 赋予 发 送 方 一 定 的 “智能 ”， 使 用 大 一 点 但 仍然 安全 的 初始 
值 。 根 据 我 的 经 验 ， 在 这 一 块 是 很 有 提升 空间 的 ， 因 为 传统 的 TCP 协 议 
栈 的 初始 值 在 现代 网 络 中 显得 实在 太 小 了 。 

措施 6: 局 用 TCPTimestamps。 

在 本 书 的 《一 篇 关于 VMware 的 文章 》 一 文中 ， 已 经 介绍 过 延迟 确 
认 是 如 何 影响 性 能 的 。 不 难 理解 ， 它 也 会 严重 影响 RIT 的 统计 。 我 们 需 
要 精确 地 监测 延迟 时 间 来 预防 拥塞 ,就 必须 在 两 边 都 启用 TCP 


Timestamps ( 见 RFC 1323 的 RTTM 一 节 ) 来 排除 延迟 确认 等 因素 的 干 
扰 。 这 也 是 双边 加 速 的 好 处 之 一 ， 在 服务 器 上 单 边 加 速 时 很 难 排除 客 
户 端的 干扰 。 

总 结 下 来 ， 这 些 措施 合力 实现 了 这 样 的 效果 : 在 起 步 的 时 候 ， 它 
传输 得 更 快 ， 在 抢夺 带宽 的 时 候 ， 它 更 懂得 谦让 ;在 出 现 拥 塞 时 ， 它 
恢复 得 更 迅速。 此 外 它 还 能 在 一 定 程度 上 避免 拥塞 ， 识 别 零星 丢 包 等 
等 ， 因 此 流量 可 以 稳定 在 高 位 。 加 速 前 后 的 某 个 TCP 连 接 ， 流 量变 化 大 
致 可 以 用 图 6 来 表示 。 
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加 速 后 流量 图 


图 6 
本 文 提 到 的 这 些 措施 我 大 多 验证 过 ， 由 于 实验 室 中 不 存在 高 延 
迟 ， 我 还 搭 了 一 台 专 门 制造 延迟 和 丢 包 的 路 由 设备 来 仿真 。 其 中 部 分 


措施 更 是 在 用 户 环境 中 验证 过 多 次 。 因 此 可 以 信心 满 满 地 说 ， 这 个 加 
速 器 在 技术 上 是 完全 可 行 的 。 那 现在 市 面 上 的 加 速 器 采用 的 也 是 这 些 
技术 吗 ? 从 部 分 公司 所 公布 的 文档 上 ， 我 的 确 看 到 了 一 些 交集 ， 当 然 
它们 还 用 到 了 压缩 和 消 重 等 TCP 之 外 的 拉 术 。Wireshark 在 加 速 颖 领域 
也 是 大 有 可 为 ， 这 就 是 为 什么 它 的 主要 捐助 者 是 加 速 右 的 领头 于 
Riverbed ° 


